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! DSTRECRDS -- DEFINITION FILE FOR THE DEBUG SYMBOL TABLE 


i SPSS Ts SM SSBB BeBe eee 2 rw 2 OS S22 SST BeBe Qe Sewn —— 2 —— aves eaneneaewmresnananaae 

; Version: *v04-000" 

i eeeeeerereeeereererereereeeereerereerereereeeeeeeeeeeerereeeeereeerereteeeer 
1 


:# COPYRIGHT (c) 1978, 1980, 1982, 1984 BY 
i DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS. 
'® ALL RIGHTS RESERVED. 


ie THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND gt 
‘* ONLY IN ACCORDANCE WITH THE ree OF SUCH peat AND WITH THE 
:* INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER 


:* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE 
;* CORPORAT Lon. NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT 


:* DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS 
:* SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. 


® 
® 
+ 
® 
® 
® 
® 
® 
® 
' % 
is TRANSFERRED. ‘ 
® 
» 
t 
® 
® 
* 
® 
® 
* 
® 


IEGEGEEEEEV 


1 

! WRITTEN BY 
: Bruce Olsen August, 1980. 

: Bert Beander August, 1981 

: Bert Beander November, 1983. 
! MODULE FUNCTION 

: This REQUIRE file — thes the structure of the Debug Symbol Table 
: rated by the VAX comp ae | and iareroretes 7 the VA senupeer 
: t_ includes Vestinitions t for all field names and ‘serets used 
building or interpreting the Debug ae Table (DST). 

! DISCLAIMER 

: This interface is not qusserted by Digital. —2* the —** ymbol 
4 Table interface is believed to be correctly described here, Digital 
: $s not guerentee that all descriptions in this definition file are 
: correct and cone lete. Also, while this interface is expected to be 
: reppeneety stab ; across releases, Digital * uergetee * it 
will not change in future resseees A! _VAK DEBUG, VAX VAS, the V 

: compilers, or other sot tuere. ~conpat ibe sddtetohe t9 this 

: interface are more likely chen | eee es e 22 * —* v — 
organ izations who use this sayer lece stand some risk that 

; — will be part fatty. or weity inval syaree, by future relea B. * 
VAX DEBUG or other digi tal software. tal reserves the right to 

; make future incompatible changes to the ebug Symbol Table interface. 
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PURPOSE OF THE DEBUG SYMBOL TABLE 


The 2 Symbol Table (DST) is the Syadot table that the VAX compilers 
roduce to pass Syeyol table information to the VAX Debugger and to the 
AX Traceback facility. The DST is a penguage. lncependen symbol table 
in the sense that all VAX compilers output symbol information in the 
same format, regardless of source language. This symbol information is 
emitted into the object modules produced by the compiler. It is then 
passed —— the Linker into the executable —* file that the Linker 
enerates EBUG or TRACEBACK can then retrieve the 

rom the image file. 


The pyrpene of the Debug Fyabet Table is thus to permit the Traceback 
facility to give a symbolic stack dump on abnormal program termination 
and to permit DEBUG to support fully syabes ic debugging. Other Digital 
software may also use the DST information for various purposes. 


symbol information 


To support these purposes, the pebus Symbol Table represents all major 
aspects of program structure and data representation. It can represent 
modules, routines, lexical blocks, labels, and data symbols and it can 
represent all nesting relationships between such symbols. It can also 
describe Line number and source Line information. It can describe all 
data types supported oy DEBUG, including complex types such as record 
structures and enumeration types. In addition, it can describe arbi- 
trarily complex value and address computations. 


The Debug Symbol Table is solely intended to support compiled Languages, 
not interpreted languages. The DST representation assumes that source 
Lines have been compiled into VAX instructions and that those instruc- 
tions are *3234 executed, not interpreted. Such DEBUG facilities as 
breakpoints and single-stepping will not work if this assumption is 
violated. Similarly, it is assumed that data objects have addresses 
that can be accessed directly when these objects are examined or depo- 
sited into. DST information is thus —— 7 all compilers that 
~ —— pypeerts. but not by the interpreters for languages such as 
or . 
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GENERAL STRUCTURE OF THE DST 


This erect ten describes the general structure of the Debug Symbol Table. 
It explains how the DST is generated by the yer tous VAX yonpi lors. how 
it is passed along to executable mage file by the Linker, and how 
it is accesses in the image file by DEBUG or TRACEBACK. This section 
also 2g bes in general terms how the DST is s are ggg ot ae 
how it is subdivided into modules, routines, lexical blocks, and indi- 
vidual symbols, how nesting relationships are represented, and how data 
symbols, nc Casing their values and data types. are represented. e 
exact formats of the various Debug Symbol Table records and other fine- 
rained detail are described later in this definition file, not here, 

t the coarse structure of the DST and how that structure is accessed 
are outlined in this section. 


GENERATION OF THE DST 


The Debug Symbol Table (DST) is generated by the compilers for all VAX 
Languages Supper see by DEBUG. During compilation, the compiler outputs 
the DST for the module being compiled into the —2 object 
file. When the Linker is invoked, it does relocation and global-symbol 
resolution on the DST text and then outputs it into the executable image 
file. Beyond knowing what must be relocated, the Linker has no specia 
knowledge of the format or contents of the DST. Finally, the +e" 
reads the DST information from the executable image file during a debug- 
ing session, or Traceback reads it when giving a traceback in response 
© an unhandled severe exception during image execution. 


A compiler outputs DST information in the form of two kinds of object 
records, TBT records pee DBT records. (See the Linker manual for a 
full description of the VAX object Language accepted by the linker.) | 
ALL “*traceback"’ information goes into the TBT records and all ‘symbol 
information goes into the DBT records. When the user later Links using 
the plain LINK command, only the DST information in the TBT records are 
copied to the executable image file. These records contain enough in- 
formation for Traceback to give a call-stack traceback. If the user 
Links with the LINK/DEBUG command, all information in both the TBT and 
the DBT records are copied to the executable nope file. These records 
together give all DST information needed for ful pynpot tc debugging. 
The user can also Link with LINK/NOTRACEBACK, in which case no OST in- 
formation at all is copied to the executable image file. 


It is not possible to have the Linker copy the DBT records without also 
copying the TBT records; the information in the TBT records is required 
for the information in the DBT records to make sense. 


The “‘traceback’’ information in the TBT records includes all Module Begin 
and End DST records, all Routine Begin and End DST records, all Lexical 
Block Begin and End DST records, and ali Line Number PC-Correlation DST 
records. It ety also include Version Number DST records. All other DST 
records should be included in DBT records. 
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| 

| 

| 

| 

Most VAX compilers have a /DEBUG ques tise which in its most generat 

form has two subqualifiers: /DEBUG=(CNOJTRACEBACK,CNOJSYMBOLS). The 

unadorned /DEBUG qualifier is equivalent to /DEBUG=(TRACEBACK,SYMBOLS); 

it causes all DST information to be output. /DEBUG=TRACEBACK causes 

only the traceback information (the TBT records) to be output by the 

compiler. /DEBUG=(NOTRACE ,NOSYMBOL) causes no DST information to be 

output at all. Finally, /OEBUG=(NOTRACE,SYMBOLS) causes all DST infor- 

mation except Line Number PC-Correlation DST records to be output (this 

combination is Largely pointless although it saves some DST space). 

Note that the module, routine, and lexical block information, which 

counts as traceback information, must be output if any symbol informa- 

tion is output since it defines the scopes within which other symbols | 

are defined. | 
| 


When the Linker outputs the Debug Symbol Table to the executable image 
file, it may also output two more image sections: the Global Symbol 
Table (GST) and the Debug Module Table (DMT). These two tables are 
enerated if the LINK/DEBUG command is used, not otherwise. The Global 
ymbol Table contains records for all globa yee known to the Linker 
in the current user program. DEBUG uses the GST as a symbol table of 
last resort when DST information is not available, either because the 
module ae some global symbol was compiled without DST informa- 
tion being output or because the module is not set (with SET MODULE) in 
the current debugging session. The GST information is not as complete 
as the DST information for the same symbols because the GST has no type 
description (the Linker does not need to know about data types). 


The Debug Module Table (DMT) is an indexing structure for the DST. It 
contains one record for each module in the DST. This record contains 

a@ pointer to the start of the DST for the corresponding module, the size 

of the DST for that module, the number of PSECTs in that module, and the 

address ranges of ail those PSECTs. The DMT allows DEBUG to initialize 

its Module Table and its Static Address Table without actually —24 to 
read through the entire DST; because the DMT is very small compared to 
the DST, it can be scanned much more efficiently. 


The details of how the DST, the GST, and the DMT are accessed in the 
executable image file are explained in the next section. 


——————————————————————— tt? — — — —— — — — — — —— 


{ 
i 
| 
| 
l 
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long 
long 
long 
long 
Long 


LOCATION OF THE DST WITHIN THE IMAGE FILE 


The Debug — Table is accessed —2 pointer information found in 

the executable image file header block. This header block contains a 

pernser in a fixed location CTHDSW. SiNGBGOFF) which points to a small 
lock Later in the header which gives the size and location of the 

Debu 8 Table (DST), the Global Symbol Table (GST), and the Debug 

Module Table (DMT). The first part of the executable image file header 

looks as follows: 


Here IHD$W_SYMDBGOFF contains the byte offset relative to the start of 
the header of an Image Header Symbol Table ag Fi pet The Image Header 
Symbol Table Descriptor (IHS) in turn has the following format: 


teocee= PPO SO OS OO OS OS OSS SS See SST SSeS SSS SSeS esses eeeesseseescee + 
‘ ~TWSSL_ “DSTVBN 
$ “THSSL ~SSTVBN H 
; IHS$W _GSTRECS 1 IHS$W_OSTBLKS H 
, 1HSSL “DATVBN H 
: IHSS$L DMTBYTES ' 
¢woeeewoeecen ere ete see ce meen eee ee neo tee ese seer ee ores me ese cee soos es > 


Here IHS$W_DSTBLKS and IHSS$L ooStven give ~~ size. {in blocks) and bes * 
tion (Virtual Block Number) Of the D bua 3 (DST) within 
executable image file. The fields ttt ¢ Thets. —— IHS$L_GSTVBN give 
the size (in GST receréss and start location (Virtual Block Number 

the Global Symbol Table (GsT). Finally, the fields IHSS$L_DMTBYTES and 
IHSS$L_DMTVBN give the size (in bytes) and start pogat ton Wirtual Block 
Number) of the > Cetus Module Table (DMT). The DMT is akettanee below. 
These field names are declared by macros in SSS, IBRA RY:LIB * 2. The 
symbol — E SYMDBGOFF is aiso defined in SYSSLIBRARY:LIB.L3 


Pointers to the Image pater and the Image Header Symbol Table Descrip- 
tor are declared as follow 


—ñ —n — 
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IHDPTR: REF BLOCKE BYTE) 
IHSPTR: REF BLOCKCLHSSK_LENGTH, BYTE) 


The Image File Header in an executable image file points to the rete 
Header erg? Table »Sescriptor as described above. If bit 4 of fie : 
IHDSL stk us * * e * e header is set, this is a ‘‘new 3* 

d by the VMS V4.0 or Later Linker, and the ngs. DM Sin’ ond 


Thst oR —— tletas A in the Image Header Symbol Tablé descriptor. 


s not set, this is an “‘old’’ ima me © and those fields do not 
a3 ) If non-zero, IHSSL_DMTVBN gives t irtual Block Number in 
the image file of the Debug” ene able (the. ol IHS$L heii 
then gives the size of the DMT in bytes. The DMT is ont uilt if the 
user did a LINK/DEBUG; if he did not, IHS$L nSMT VEN and IHSSL_DM*3YTES 
are zero. 


The Debug Module ‘= 


e contains one entry per module in the Debug 
Symbol Table (the DST) 


l 
T). This is the format of each such DMT entry: 


‘ Size in bytes of “nodule’ a DST H 
i Unused=~Must Be Zero * “Number of PSECTs for module ; 


ewer wre se eee eee ew wee w mm meteor moe} mre memo e mero e ee mo we eee eo oe wee oe $+ 


: “Start address of first “PSECT in nodule 


$e em owen eececetenoee= SRS Se SOP ee eS RO eH NE MOE BO DOE EE OBO EOE Oe eee ee 


Length of first PSECT in nodule in bytes 


; (Two longwords per PSECT) 


*2222— — 2— RS eS ee ee SOB anr eran mar nae renee e 


H Start address of last PSECT in _module 


Lonevers 0 gives the address relative to the start J ive DST of the 
Module B Beat? 8> DST socare for this module. —— ves the size 

of the DST in bytes for the same module. Longword 2 81 ves the number 

of PSECTs in the module (i.e., the number of statically allocated 

program sections), and this is followed by that number of two-longword 

perrt which give the start address and length (in gytes? of each such 

- Since the number of PSECTs cannot exceed 65K, the upper two 
bytes of longword 2 are available for future expansion. 


The DMT is used dur ing * initialization to initialize DEBUG's Run- 
Time Symbol Table (RST) and Program Static Address Table (Program SAT). 
Using the DMT is much faster than the alternative procedure, namely 

reading through the entire DST to pick up the needed information. The 
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information in the DMT — is enough to build a Module RST Entry for 
each module in the DST and the PSECT information is used to build the 
Program SAT. The amount of RST symbol table space needed per module is 
not computable from the DMT information, but is estimated by multiplying 
the DST size of each module by an appropriate scale factor. 


OVERALL STRUCTURE OF THE DST 


The Debug Symbol Table consists of a cont tquays Sequence of DST records. 
Each DST record contains a two-byte header which gives the length of the 
record in bytes and the type of the record. The structure of the rest 
of the record (if * is determined by the record type. The Length of 
the DST in 512-byte blocks is Nhe gg in the image file header; if the DST 
does not fill the Last block, that block is zero-padded to the end. 


The largest structural unit within the DST is the module. Each module 
represents the symbol table information of a yeperatety compiled object 
module. The DST for a module always begins with a Module Begin DST rec- 
ord and ends with a Module End DST record. The Module Begin DST record 
gives the name of the module and the source language in which it was 
written. The Module End DST record simply marks the end of the module 
and contains no other information. As noted above, if present, the 
Debug Module Table (DMT) points to the Module woaie DST record of each 
module represented in the DST. DEBUG uses the DAT (if present) to lo- 
cate all modules in the DST. 


The DST as a whole thus onuere begins with the Module Begin DST record 
for the first module in the DST. It is followed by the symbol informa- 
tion for that module. Then comes the Module End DST record for that 
module. Immediately after that Module End DST record comes the Module 
Begin DST record for the next module, and so on to the end of the whole 
DST, where the Module End DST record for the last module is found. The 
rest of that image file block is zero-filled to the next block boundary. 
Note that there is no break between modules in the DST. 


NESTING WITHIN THE DST 


For most languages, the symbol table must represent a variety of nesting 
relationships. Routines are nested within modules, data ove ols are 
declared within routines, and even routines are nested within routines. 
Certain data constructs, in particular record structures, contain addi- 
tional nesting relationships. In the Debug Symbol Table, such nesting 
relationships are represented by Begin-End pairs of DST records. We 
have already seen above that the largest subunit of the DST, namely the 
module, is represented by a Module Begin DST record and a Module End DST 
record bracketting the DST information for the module. 


This principle extends to other nesting relationships. The DST informa- 
tion for a routine is thus represented by a Routine Begin DST record and 
a Routine End DST record enclosing the DST information for all symbols 
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local to or nested within that rout ine. imilarly, lexical blocks (such 
as BEGIN-END blocks or their equivalents in various languages) are re- 
resented by Block Begin and Block End DST records enclosing the symbol 
ST records local to that lexical block. The nesting of routines and 
blocks within one another to any depth (within reason) is represented by 
the proper nesting of the corresponding Begin and End DST records. 


An example J help clarify this notion. 
program in a fi 


Program Structure 


MODULE M = 
BEGIN 
VAR SYM_M1: INTEGER; 
VAR SYMIM2: REAL; 


ROUTINE R1 = 
BEGIN 


ROUTINE R2 = 
VAR SYM_R21: DOUBLE; 
VAR_SYM-Re2: INTEGER; 
ROUTINE -R2A = 


BEGIN 
VAR SYM_R2A: BYTE; 
BEGIN 


VAR BLK_V1: WORD; 
ROUTINE R2BLER = 


FOO:BEGIN 


The following example shows a 
ctitious language along the corresponding sequence of DST 


DST Record Sequence 


Module Begin ſ 


Data SYM_M1 (DTYPE_L) 
Data SYM~M2 (DTYPE-F) 


Routine Begin R1 


Data SYM_R11 (BOOLEAN) 
Data SYM_R12 (DTYPE_L) 
Routine End (for R1J 


Routine Begin R2 


Data SYM_R21 (DTYPE 
Data SYM_R22 (DTYPE 
Routine Begin R2A 


Data SYM_R2A (DTYPE_8) 
Block Begin (no name) 
Data BLK_V1 (DTYPE Ww) 
Routine Begin R2BLRR 


Block Begin FOO 


D) 
L) 


FOO_V:REAL; Data FOO_V (DTYPE_F) 


VAR R2BLK_V2:REAL; 
END; 


VAR BLK_V2: DOUBLE; 
END; 


END; 
VAR SYM_R23: REAL; 
END; 


Here module (compilation unit) M contains two 


Block End (for FOO) 


Data R2BLK_V2 (DTYPE_F) 
Routine End (for R2BCKR) 


Data BLK_V2 (DTYPE_D) 
Block End (for no name) 


Routine End (for R2A) 


Data SYM_R23 serves F) 
Routine End (for R2y 


Module End 


module-level data items, 
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SYM_M1 and SYM_M2, and two routines, R1 end R2._ Routine R2 in turn con- 
tains several Togat cate symbols (SYM_R21, SYM_R22, and SYM_R23) and a 
nested routine R2A. R2A in turn contains an anonymous BEGIN-END block, 
that blocks contains two local data grapes BLK_V1 and BLK_V2 and a 
Local routine R2BLKR, local routine R2BLKR contains a data symbol and a 
Labelled BEGIN-END block FOO, and block FOO contains one local symbol 
FOO_.V. ALL this nesting is represented 7 Begin and End DST records in 
the Debug Symbol Table as illustrated on the right. 


Additional nesting must be represented for data. A record (called a 
structure in some languages) is a gonpes tte data object containing some 
number of record components of various data types. A record component 
may itself be a@ record. In addition, some Languages allow records to 
have ‘‘variants’’ (as in PASCAL), which imposes additional structure that 
must be represented in the DST. 


A record type is represented by a Record Begin and Record End DST record 
pair nice aoe bby the DST records for the record components. This notion 
is illustrated by this program segment and the corresponding DST: 


Program Structure DST Record Sequence 
TYPE RECTYP = Record Begin (RECTYP) 
RECORD OF 
COMP1: INTEGER; Data COMP! (DTYPE_L) 
COMP2: REAL; Data COMP2 (DTYPE_F) 
COMPS: DOUBLE; Data COMPS (DTYPE D) 
END; Record End (for RECTYP) 


Here RECTYP is a record type. Each seiece of this type is a record con- 
taining three components, COMP1, COMP2, and COMP3. is structure is 
represented in the DST by a Record Begin DST record followed by Data DST 
records for the components followed | a Record End DST record. The 
addresses specified in the component DST records are bit or byte offsets 
from the start of the RECTYP record as a whole. 


In this example, the Record Begin DST record for RECTYP ney in fact re- 
greqers either a record type or a record object. A field in the Record 
egin DST record indicates which. However, let us assume that RECTYP 
defines a record type. How do we then declare objects of that type? 

The following example illustrates how: 


Program Structure DST Record Sequence 


Data REC1 {Sept ypSpac) 


TYPE RECTYP = Record Begin (R P) 
RECORD OF 
COMP1: INTEGER; Data COMP! (DTYPE_L) 
fe: REAL; Data COMP2 (DTYPE_F) 
COMPS: DOUBLE; Data COMPS (DTYPE D) 
END; Record End (for RECTYP) 
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Data REC2 (SepTypSpec) 

Type Spec DST record 
(Indirect Type Spec 
pointing to RECTYP) 


Here the same record type RECTYP is defined. Two objects of that type 
are also defined, REC] and REC2. Both data objects are represented by 
Separate Type Specification DST records. Such a DST record must be im- 


mediately followed by a DST necord that defines fre symbol's data type. 
The REC1 Separate Type Specification DST record is immediately followed 
by the RECTYP Record Begin DST record; hence REC1 is of the RECTYP data 


CT 
type. The REC2 Separate Type Specification DST record is immediately 
followed by a Type geec ification DST record. This record contains an 
Indirect Type Specification that points back to the Record Begin DST 
record for RECTYP. Hence REC2 is also of that record type. 


Records may be nested in the sense that a record component may itself be 
an object of some record type. A record component of a record type is 
Sg heey the same way as ”~ other object of a record type, namely by 
a Separate Type Specification DST record. This record must be followed 
by a Record Begin DST record or by a Type Specification DST record that 
points to a Record Begin DST record. e record component can also be 
represented by a Record Begin DST record directly if this record is 
marked as defining an object rather than a type. 


Record variants, as found in PASCAL, introduce additional structure. A 
detailed description of how variants are represented in the DST is found 
in the section on ‘Record Structure DST Records’’ Later in this defini- 
tion file. Here we will only give an example that illustrates the gene- 
ral scheme that is used: 


Program Structure DST Record Sequence 
Data REC1 tSeptypsec) 
TYPE RECTYP = Record Begin (RECTYP) 
RECORD OF 
COMP1: INTEGER; Data COMP! (DTYPE_L) 
CASE TAG: BOOLEAN OF Data TAG (BOOLEAN 


Surtant "¥olee for FALSE 


FALSE: (¢ 
COMP2: REAL; Data COMP2 (DTYPE_F) 
COMPS: DOUBLE); Data COMPS (DTYPE_D) 
TRUE: ( Variant Value for TRUE 
COMP4: INTEGER); Data COMP4 (DTYPE_L) 
END CASE; Variant Set End 


END; Record End (for RECTYP) 
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— — — — ee ee ee ee — —— 


VAR REC1: RECTYP; 


Nesting is also used to describe enumeration types as found in PASCAL 
and some other languages. An enumeration type is Gesce bed by an Enum- 
eration Type Begin DST record followed by Enumeration —* Element DST 
records for all the enumeration literals of the type followed by an 


Enumeration Type End DST record. Any actual object of the enumeration 
type must be described by a Separate Type Specification DST record. 
eM example illustrates what the DST for an enumeration type looks 
e: 
Program Structure DST Record Sequence 
Data HUE (Sept ypspec) 
TYPE COLOR = ( Enum Type Begin COLOR 
RED Enum Type Element RED 
GREEN, Enum Type Element GREEN 
BLUE Enum Type Element BLUE 
); Enum Type End (COLOR) 
VAR HUE: COLOR; 
VAR PAINT: COLOR; Data PAINT (SepTypSpec) 


ype Spec DST record 
(Indirect Type apes 
pointing to COLOR) 


A more detailed description is found in the section entitled ‘'Enumera- 
tion Type DST Records’* Later in this definition file. 


For some DST record types, DEBUG pore all nesting relationships below 
the module level. ne Number PC-Correlation DST records, for example, 
may be scattered throughout the DST for a module. DEBUG treats all such 
DST records as defining the Line number information for the module as a 
whole, regardless of how they may be scattered within or outside the 
routines and blocks of the module. Starter ty Source File Correlation 
DST records may be scattered throughout the §1T for a module. Records 
such as these can be generated wherever the compiler finds it most con- 
venient to generate them. 


DATA REPRESENTATION IN THE DST 


Data Symbols are described in the DST by a variety of representations. 
Fundamentally, all such representations give three pieces of information 
about each data symbol: its name, its address or value, and its data 
type. DEBUG needs additional information about a data symbol. in parti- 
cular its scope of declaration, but that information is implicit in the 
nesting structure of the DST as described above. 


The name is given by a Counted ASCII string in the data symbol's DST 
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record. The value or 26 can be given by a five-byte 2 con 
taining one byte of control information and a longword address, offset, 
or value. However, if this five-byte encoding is not adequate to de- 

scribe the address or value, escapes to a more complex value specifica- 
tion later in the DST record are available. The data type ow be repre- 
sented by a one-byte type code, but if that is not adequate there are 

several escapes to a more complex type description elsewhere in the DST. 


The standard five-byte value specification can specify any 32-bit or 
smaller Literal value, y By byte address, any register address, 
and any address that can formed H one indexing operation off a reg- 
ister or one indirection or both. a VAX Standard Descriptor exists 
for the symbol in user memory, the five-byte *—* can describe the 
descriptor address by any of the above means; the actual data address is 
then retrieved from the descriptor. 


The standard eieerbyte value specification is adequate for the bulk of 
all data symbols. However, there are cases when it is inadequate. It 
cannot describe Literal values longer than 32 bits, it cannot describe 
very complex address computations, and it cannot describe bit addresses 
unless an appropriate descriptor is available in user memory. for these 
cases, the first byte of the five-byte encoding must have one of several 
special escape values. The remaining longword then contains (in most 
cases) a pointer to a more complex value specification later in the same 
DST record. That more conpces value epee’ Ssgat ten a consist of a VAX 

*VS-Follows’’ Value Specification. A VS-Follows 
Value Specification can, in the most complex case, contain a routine to 
be executed by DEBUG to compute the desired value or address. This rou- 
tine may even call compiler-generated thunks when the complexity of the 
address computation so requires. 


The details of these more complex value specifications are given in the 
section entitled ‘DST Value Specifications’’ later in this definition 
file. The point being made here is simply that the DST provides a 
simple and compact value specification mechanism that is adequate for 
all simple cases, but it also provides several escapes to arbitrarily 
complex DST Value Specifications. These complex value specifications 
are capable of describing all known address and value computations 
required by the languages supported by DEBUG. 


For all simple, 


i 


atomic data types, a single type byte describes t 
symbol. However, there are several escape mechanisms for more complex 
data types. One mechanism is to take the type information from a 
Standard Descriptor found either in user memory or in the DST. Another 
is to use a Separate Type Specification DST record for the data symbol. 
The data type is then described by a second DST record which immediately 
follows the Separate Type Specification DST record. This second record 
must be a Record Conia ST record (describing a record type? an Enume- 
ration Type Bogie DST record seesce tb ing an enumeration ype), or a Type 
Specification DST record. A type Specification DST record can describe 
any data type supported by DEBUG. t contains a DST Type Specification 
for the data type in question. This Type Specification may be an Indi- 
rect Type Specification, pointing to ST record elsewhere in the DST 
that defines the data type. Alternatively, it may describe the desired 
data type directly and may be as complex as the data type requires. 
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FIELD ACCESS MACROS 


The following macros are used in Set tates BLISS field names for all — 
structures in the Debug Symbol Table. These macros supply the position, 
size, and sign-extension values when used in FIELD declarations for 
BLOCK and BLOCKVECTOR data structures. They are used instead of their 
numeric equivalents because og | are clearer and less error-prone. The 
os frees generic forms (as specified by the letters in the names) are as 
ollows: 


A Materialized address 

L Longword 

W Zero-extended word 

8 Zero-extended pyte 

V Zero-extended bit field 
Sw Sign-extended word 

$B Sign-extended pyte 

SV Sign-extended bit field 


The “‘A’’ form should be used whenever the field being defined is such 
that only the address of the field may be materialized in a structure 
reference; that is, fetch and store operations on the field are not 
valid. An example of such a field is an ASCII string. 


Each of the ‘V’’ and “Sv"’ forms take one or two parameters. The first 
parameter is the bit position within the as or byte and the 
second is the field size in bits. The second parameter is optional: 

if omitted, it defaults to 1. Thus V_(5) means bit 5 while V_(5,3) 
means the $-bit field starting at bit 5 and ending at bit 7. t 

poses sone are counted from the low-order (least significant) end of the 
ongword, starting at zero. 


This following field access macros are used in DSTRECRDS.REQ. Their 


actual definitions are found in STRUCDEF.REQ, but are shown here for 
the convenience of the reader. 


$B 
SV~(P,S)= P, SIF ZNULL(S) XTHEN 


MACRO 

AL = 0, 9. 93. ! Address of a field 

Oe = 0, 32, 0, ' Longword 

wv a: & & Fk ! Word, zero-extended 

B_ = 0, 8 O22 ! byte zero-extended 

VI(P,S) = P, RIF ZNULL(S) ZTHEN it USES HEI. 0 %, ! Unsigned 
. e 

Su_ = 0. 18. 1%, ! word, sign-extended 

= 0, 8 12% i 

i] 


exte gtgnrensended 
ZELSE § 2F1, 1%, ! Signed 
bit field 


Bring in the field access macro definitions from STRUCDEF.L32. 
IBRARY ‘*LIBS:STRUCDEF.L32'; 


lo ee te te te ee ee ee eee ee eee ee 


i 
OO — —i — — — 
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THE DST RECORD 


ALL DST records have the same general format 
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HEADER FORMAT 


consisting of a fixed 


two-byte header followed oy fre or more fields whose format i 


determined by the DST recor 
records: 


$s 
s type. This is the format of all DST 


teoe snr ee eee Em e DEON 


byte ‘ DSTSB_LENGTH : 
byte ‘ DSTSB_TYPE H 

SOE O88 SSS OSS SSS SS SSS SS SSSSSSSSSSSSSSSSSSESSESOSGSSSCSCSCeSeGCees$} 
var DSTSA_NEXT 


These fields appear in all DST records. 
IELD DSTSHEADER_FIELDS 


DSTSB_LENGTH =6= (0,8), ! 
DST$B_TYPE 24.6 3.7593 
DST$A_NEXT — 


TES; 


Zero or more additional fields depending on 
the value of the DSTSB_TYPE field 


4 ieee etait 


! The Length of this DST record, not 


wns Luding this length byte 
The type of this DST record 


' The next DST record starts at this 


location plus DST$B_LENGTH 


— 


——- 
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SUPPORTED VALUES FOR DSTSB_TYPE 


ALL Supper tes values of the DST record type field (DST$B TYPE) are 
listed here. If the yalye is in the range of DSCSK_DTYPE_LOWEST to 
DSCSK_DTYPE_HIGHEST, it is a VAX Standar Type Code and gives the 
data type of the object being defined s case, the record is 
a Standard Data pet secore or one of its variants. Ot 


value. ALL other type pps 

between DSCSK_DTYPE_HIGHEST and DSTSK_LOWEST are reserved for future 
use by Digital. The type codes in the renge 19 255 

reserved for use bY customers, although DEBUG does not support any 
—_ type codes. DE 

codes. 


VAX STANDARD TYPE CODES 


As mentioned above, VAX Standard Type Codes can be used as DST record 
tye codes for data symbols. The type code then gives the data —* 
of the symbol in addition to indicating that the OST record has the 
Standard Data DST record format or a variant thereof. 


ALL VAX Standard Type Codes are Listed here for convenience. They are 
commented out since they are actually declared in STARLET.REQ. 


! $k 2 = 0, ! Unspecified (May not appear in DST). 
! DSCSK_DTYPE_V = 1, ! Bit. 

! DSC$K_DTYPE—BU = ¢° ! Byte logical. 

! DSCSK_DTYPE_wWu = 3, ! Word logical. 

! DSCSK_DTYPE_LU = 4, ' Longword logical. 

! DSCSK_DTYPE_QU = 5, ! Quadword logical. 

! DSCSK_DTYPE_B = 6, ! Byte integer. 

! DSCSK_DTYPE_W = 7, ! Word integer. 

! DSCSK_DTYPE_L = 8. ' Longword integer. 

! DSCSK_DTYPE_Q = ! Quadword angeger. 

! DSCSK_DTYPE_F = 10, | Sin le-precision floating. 

! DSCSK_DTYPE_D = 11, ! Double-precision floating. 

! DSCSK_DTYPE_FC = 3 —*æ 

! DSCSK_DTYPE_DC = 15, ! Double-precision Complex. 

! DSCSK_DTYPE_T = 14, ! ASCII text string. 

! DSCS$K_DTYPE_NU = 15, ! Numeric string, unsigned. 3 

! DSCSK_DTYPE_NL = 16, ! Numeric string, left separate sign. 
! DSCSK_DTYPE_NLO = 17, ! Numeric string, left overpunched sign. 
! DSCSK_DTYPE_ = 1. ! Numeric string, right separate sign. 
! DSCSK_DTYPE_NRO = 19, ! Numeric string, right overpunched sign 
! DSCSK_DTYPE_NZ = 20, ! Numeric string, zoned sign. 


| 
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Packed decimal string. 

Sequence of instructions. 

Procedure entry mask. 

descriptor. used for arrays of 
c 


dynamic strings 
Octaword pogical 
Octaword inte 


er 
Double recisten G floating, 64 ptt 
Quadruple precision floating, 128 bit 
Double precision complex, G floating 
Quadruple precision complex, H floa ing 
COBOL intermediate temporary 

Bound Procedure Value 

Bound Label Value 

Bit Unaligned 

Absolute Date-Time 

Unused (not supported by DEBUG) 

Varying Text 


The next two values are used for range checking of the type values 
in DST entries. They are used mainly in CASE statements. 


SCSK_DTYPE_LOWEST = 1 ! Lowest DTYPE data type we support 
SC$K_DTYPE_HIGHEST = 37; i Highest DTYPE data type we support 
INTERNAL TYPE CODES FOR DEBUG 
: 
i 
: The following definitions are used internally in DEBUG, but are not 
: supported in the DST. They should be deleted here if they are made 
: into standard VAX type codes declared in STARLET.REQ. These numbers 
4 may change from one release of DEBUG to the next because they must 
always be larger than DSCSK_DTYPE_HIGHEST. 
: 
: Define DEBUG-internal type codes. 
LITERAL 
DSCSK_DTYPE_AC = 38, ! ASCIC Text 
DSCSK_DTYPE_AZ = 39, ! ASCIZ Text 
DSCSK_DTYPE_TF = 40, ! Boolean True/False (length in bits) 
DSCSK_DTYPE_SV = 41, ' Signed bit-field (aligned) 
DSCSK_DTYPE_SvU = tg: ! Signed bit-field (unaligned) 
DSCSK_DTYPE_FIXED = 45, ! Fixed binary used for FIXED in ADA 
and FIXED BINARY in PL/I. This 
: code is used the type conversion 
: tables in DBGEVALOP. 
! The following Literals are used as CASE statement bounds internally 
in DEBUG for the range of DIYPE codes used. 


LITERAL 


! BLISS 
! other 


LITERAL 


' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
' 
i 
‘ 
i 
i 
L 
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DBGSK_MINIMUM_DTYPE = 0 
DBGSK-MAXIMUM_DTYPE = 4$; 


Lowest internal DEBUG dtype value 
Highest internal DEBUG dtype value 
The following definition is only used internally in DEBUG. It is 

a DTYPE code that is temporarily put into a Value Descriptor to 
tell the address expression interpreter that the Value Descriptor 
came from a Literal constant. It does not have to be in the above 
range because it is only used during the ——— of address expres- 
sions. After the address expression has been —— if the DIYPE 
is LITERAL, it is then changed to DSCSK_DTYPE_L. 


DSCSK_DTYPE_LITERAL = 191; ! Value is from a Literal constant 


OTHER DST TYPE CODES 


The following Literals are the DST *8 codes other than VAX Standard 
oye Codes which can appear in DSTSB_TYPE. Each indicates the format 

of the record which contains it and most indicate the kind of object 
being described by that record. When new DST records are defined, the 
type code is assigned by — DSTSK_LOWEST one smaller and using that 
value. The type codes above p TSK_HIGHEST (191) are reserved, the idea 
penne that the DITYPEs 192 = 255 are architecturally reserved to users. 
DEBUG ignores all DST records whose type codes are not DST$SK_BLI, in 
the 31 from DSCSK_DTYPE LOWEST to DSCSK_DTYPE_HIGHEST, or in the 
range DSTSK_LOWEST TO DSTSR_HIGHEST. 


i Define all Additional Debug Symbol Table record type codes. Note —— 


Special Cases record has code zero (for historical reasons). 


type codes are in the range DSTSK_LOWEST to DSTSK_HIGHEST. 
DSTSK_BLI = 0, SLISS Special Cases Record 
DST$K_LOWEST = 153, ! Lowest numbered DST record in this 
: renge~ wand for range checking 
DSTSK_VERSION = 153, ! Version Number Record 
DSTSK_COBOLGBL = 154, ! COBOL Global Attribute Record 
DST$K_SOURC = 155, ' Source File Correlation Record 
DSTSK_STATLINK = 156, ! Static Link Record 
DSTSK_VARVAL = 157, ! Variant Value Record 
DSTSK_| = 158, ! Atomic object of type BOOLEAN, 
’ Allocated one byto. 
; low order bit = 1 if TRUE 
i low order bit = 0 if FALSE. 
DSTSK_EXTRNXT = 159, ! External-Is-Next Record (Obsolete) 
DST$K_GLOBNXT = 160, ! Global-Is-Next record (Obsolete) 
DSCSK_DTYPE_UBS = 161, ! DEBUG internal use only (unaligned 
: bit string) (Obsolete) 
DST$K_PROLOG = 162, ! Prolog Record 


— — 
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— — — — — · · 


DSTSK_SEPTYP = 163, ! Separate Type Specification Record 
DSTSK_ENUMELT = 164, ! Enumerated Type Element Record 
DSTSK_E EG = 165, ! Enumerated Type Begin Record 
DSTSK_ENUMEND = 198. ! Enumerated Type End Record 
DSTSK_VARBEG = 167, ' Variant Set egin Record 
DSTSK_VAREND = 168, ! Variant Set End Record 
DSTSK_OVERLOAD = 19) ! Overloaded Symbol record 
DSTSK_DEF_LNUM = 170, ! Definition Line Number Record 
DSTSK_RECBEG = 171, : Record Begin Record 
DSTSK_RECEND = 17 ! Record End Record 
DSTSK_CONTIN = 173, ! Continuation Record 
DSTSK_VALSPEC = 174, ' Value Spegitice ion Record 
DSTSK_TYPSPEC = 175, } type Specification Record 
DSTSK_BLKBEG = 178. ! Block my Record 
DSTSK-BLKEND = 177, i Block End Record 
DSTSK_COB_HACK = 178, ' COBOL Hack Record (Obsolete) 

: = 179, ! Reserved to DEBUG 

‘ = 180, ! Reserved to DEBUG 
DSTSK_ENTRY = 181 ! Entry Point Record 
DSTSK_LINE_NUM_REL Rif ! Threaded Code PC-Correlation 

⸗ 3 Record (Obsolete) 

DSTSK_BLIFLD = + ° ! BLISS Field Record 
DSTSK_PSECT = 184, ! PSECT Record 
DSTSK_LINE = 185, ! Line Number PC-Correlation Record 
DSTSK_LBLORLIT = 186, ' Label-or-Literal Record 
ST$K_LABEL = 187, ! Label Record 
DSTSK_MODBEG = 188, !' Module Begin Record 

STSK_MODEND = 189, ! Module End Record 
DSTSK_RTNBEG = 190, ! Routine Begin Record 
DSTSK_RTNEND = 191, ! Routine End Record f 
DSTSK_HIGHEST = 191; } Highest numbered DST record in this 


range--used for range checking 
NOTE TO DEVELOPERS: 


New DST Records should not be added at this end of the DST record number 
53 — VAX Standard Type Codes 192 - 255 are reserved to users. Hence 
DEBUG does not use type codes in that range, even though DEBUG does not 
support user-defined type codes. New DST record numbers should be allocated 
by decrementing DSTSK ESf and using that number for the new DST record. 
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MODULE DST RECORDS 


The Debug syabol Table for each separately compiled module must be 
enclosed within a oes en fy Sey elt oy pair 9 DST records. The 
Module Begin DST record must thus be the very first DST record for 

any poporatety compiled module (i.e., any object file) and the Module 
End DST record must be the very last DST record for the module. Only 
one — ges | ke aay pair is allowed in what the Linker sees 

as a single object module. (If 344 Module-Begin/Module-End pairs 
are included in one object module, DEBUG will only see the first such 
pair and ignore the rest because the Linker will only tell DEBUG about 
the location of the first Module Begin record.) 


The Rody} o- Sento Madylontne pair defines a symbolic scope which con- 

tains all symbols defined by DST records within that pa r. The module 
has the name given in the Module Begin DST record. The language of the 
object module is also encoded in the Module Begin record. 
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THE MODULE BEGIN DST RECORD 


The Module Begin DST Record marks the beginning of the DST for a module. 
This DST record also gives the name of the module and the source lLan- 
guage in which the module was written. The Module Begin DST Record 

must be the the first DST record of every compilation unit ('‘module’’) 
and it must be matched by a Module End DST Record that ends the DST for 
that module. Only one Module Regn DST Record is allowed to appear in 
the DST for a separately compiled object module. 


This is the format of the Module Begin DST Record: 


————— — — — —— + 


DSTS$B_LENGTH 


$b ewmmes ser acresnces — —— —— — FSKQe WBN SBas ——2—— wonoma > 


' DSTSB_TYPE (= DSTSK_MODBEG) ' 


ber eosan nen eme sana mean can man eseeeoeo See aoe oMnoeama men nanwmaneeanan 


' DST$B_MODBEG_UNUSED ' 


42— —— ——— SEQ TeETBB Oe SBF FSB SSBHSEe Ges ———2— see owen ce = +> 


' DSTSL_MODBEG_LANGUAGE ' 


emcee mae stern — wesw ener roars canomeaecomacanae eSeeeeaeoeae — 


DSTSB_MODBEG_NAME 


The Module Name in ASCII 
(The name's Length is given by DST$B_MODBEG_NAME) 


@ cocccccccccs > oo 


Define the fields and size of the Module Begin DST Record. 
IELD OST HROSEES_F SELOS = 


' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
: byte 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
Ff 


LITERAL 


DST$B_MODBEG_UNUSED = f » & 2. ! Unused--Must Be Zero 
DSTSL_MODBEG_LANGUAGE = » kL de : Language code of language in 

: which module was written 
DST$B_MODBEG_NAME =C€ 7, 8B ' Count byte in name counted 

: ASCII string 
TES; 
DSTSK_MODBEG_SIZE = 8; ! Size in bytes of the fixed part of 

; the Module Begin DST record 


! Define all the Language codes that may oppear in the DSTSL_MODBEG_|ANGUAGE 


! field of the Module Begin DST record. 


ote that DEBUG may not actually 


support all languages that have language codes.) 


LITERAL 
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DSTSK_MIN_LANGUAGE = 0, ' Smallest Language code 
DSTSK_MACRO = 9. ! Macro — 
DSTSK_FORTRAN = 1, ! Fortran 

DSTSK_BLISS = ¢° ! Bliss 

DSTSK_ COBOL = 3, ! Cobol 

DSTSK_BASIC = 4, ! Basic 

DSTSK_PLI = 5, ' PL/I 

DSTSK_PASCAL = g. ! Pascal 

DSTSK_C = 7, '¢ 

DSTSK_RPG = 8, ' RPG 

DSTSK-ADA =9 i Ada 

DSTSK-UNKNOWN = 16, i Language Unknown 
DSTSK_MAX_LANGUAGE = 10; ! Largest language code 


! Here also we define all the same Language codes using names with the DBGS 
! prefix. This prefix is used in DEBUG for historical reasons. These names 
: may eventually be discarded. 


LITERAL 


DBGSK_MIN_LANGUAGE = DSTSK_MIN_LANGUAGE, ! Smallest Language code 
DBGSK_MACRO = DSTSK_MATRO, ! Macro 
DBGSK_FORTRAN = DSTSK_FORTRAN,! Fortran 
G$K_BLIS = DSTSK_BLISS, ! Bliss-32 
GSK_C = D.TSK_COBOL, ! Cobol 
DBGSK_BASIC = DSTSK_BASIC, ! Basic 
DBGSK_ = DSTSK_PLI ! PL/I 
DBGSK-PASCAL = DSTSKIPASEAL, | Pascal 
DBGSK_ = DSTSK_C a 
DBGSK—RPG = DSTSK-RPG, | RPG 
BGSK_ADA = DSTSK_ADA, ' Ada 
DBGSK_UNKNOWN = DSTSK_UNKNOWN,! Language Unknown 
DBGSK_MAX_LANGUAGE = DSTSK_MAX_LANGUAGE; ! Largest language code 


Language UNKNOWN requires some special explanation. DEBUG supports ‘‘unknown’’ 
cenquages with @ standard set of DEBUG functionality. This standard set in- 
cludes all language-independent functionality plus “‘vanilla-flavored" Language 
expressions. Identifiers are assumed to allow A- 2, 0 - 9, and _. Symbol 
references may include pudser ing ing (using round () or square f) parentheses) 
and record component selection (using dot=-notation as in A.B.C). Most simple 
operators are allowed in language expressions. 


While not officially supported, language UNKNOWN is intended as an escape for 
compiiers which do not yet have true DEBUG support. By specifying Language 
code DSTSK_UNKNOWN in the DSTSL_MODBEG LANGUAGE field, such languages can 
take advantage of whatever support DEBUG provides for unknown languages. If 
and when true DEBUG support is provided. a new Language code for the new 
language can be allocated | incrementing DSTSK_MAX_LANGUAGE by one and as- 
signing that Language code to the new language. 


Use of the DSTSK_UNKN Language code 
or any out-of-r Language code is intended for internal use by Digital 
only. DEBUG's unknown- anguage support is not officiaicy supgor ed and is 
subject to possibly incompat of DEBUG. 


lec 
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i Internally, DEBUG 
' guage code above 


255°9 


ts the Lan 
s truncate 


qv 
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age code as a byte value, Hence any Lan- 
te its low-order eight bits. — 
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THE MODULE END DST RECORD 


1 

i 

1 

i The Module End DST Record must be the Last DST record in the OST for a 
4 compilation unit. Its sole purpose is to mark the end of the DST for 
‘ a@ separately compiled object module. There can be only one Module End 
: DST record per module, matching the previous Module Begin DST record. 
: This is its format: 

i 

: byte : DSTSB_LENGTH (= 1) H 

byte } DSTSB_TYPE (= DSTSK_MODEND) : 

4 

: Define the size in bytes of the Module End DST Record. 

LITERAL 


DSTSK_MODEND_SIZE = 2; ! Size of Module End record in bytes 
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ROUTINE DST RECORDS 


A routine is represented in the Debug Symbol Table by a oy f DST 
records, namely a Routine Begin DST record which is matched with a 
later Routine End DST record. ALL DST records between the Routine 
Begin and the Routine End DST records represent the symbols that are 
declared in that routine or in nested routines or blocks. Nested rou- 
tines are represented in the DST by nested Rout ine-Begin/Rout ine-End 
pairs. Lexical blocks (BEGIN-END blocks or she like, Gepending on 

the panguage) may also be nested freely outsid n 


= e or inside rout 
prov 


es, 
Ll blocks and routines are properly nested. 

Consider the following example of nested blocks and routines. If 
routine R1 contains a nested routine R2 and a lexical block 81 and 
if block 81 contains routine R3 and Block B82, the DST would have the 
following sequence of DST records: 


Module Begin for whole module 
---module-level data DST records... 
Routine Begin for R1 

-» local data DST records for R1... 
Routine Begin for R2 
.. local data DST records for R2... 
Routine End for R2 
Block Begin for 61 
---local data DST records for 61... 
Routine Begin for 
-»-local data DST records for R3... 
Routine End for R3 
Block Begin for B2 
eee local Sate Det records for B62... 


Routine End for R1 
Module End for whole module 


In addition to defining a symbol scope, the Routine-Begin/Rout ine-End 
air defines the name and address range of the corresponding routine. 
he name and start address is found in the Routine Begin DST record 

and the byte length of the routine is found in the Routine End DST 

record. It is assumed that the start address is also the entry point 
to the routine. The Routine Begin record also indicates whether the 
routine uses a CALLS/CALLG Linkage or a JSB/BSB Linkage. 
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byte 
byte 


long 
byte 
var 


THE ROUTINE BEGIN DST RECORD 


The Routine Begin DST record marks the *78 of a routine and 
associated $50p¢. This record contains the routine's name and st 
address and indicates whether the routine is a CALLS/CALLG routin 
or a JSB/BSB routine. It must be matched by a Routine End DST re 
later in the DST, except if the language of the current module is 
MACRO. (Since MACRO routines have entry points but no well defin 
end points, the Routine End record can and must be omitted for th 
language. This exception applies to no other Language.) 


This is the format of the Routine Begin DST record: 


ù ——— ———4 


DST$B_LENGTH ; 


Fewer see seen es eee tD eee ee Deen we Bee oD Ee EOTESeosese } 


H DSTSB_TYPE (= DSTSK_RTNBEG) ' 


— ew aem ene arose onemroe eco cm ome mcm ema esto n ace canes eee nm awe 4222222— + 


‘ DSTSV_RTNBEG_UNUSED +NO_CALL: 


H DSTSL_RTNBEG_ADDRESS ' 


¢owmoece seco ee mew ewer ome wom oon eSeeeeaeaoeo aod 


H DSTS$B_RTNBEG_NAME ' 


prowess worm mane nec nom nm amore — sc Deen EBD een ueeanase Se eeeoeoeonoone 2 ae > em oo ae 


The Routine Name in ASCII 
(The name's Length is given by DSTSB_RTNBEG_NAME) 


— 2 2 roe — — — eee 2 —22— — —— — erent eee ese ese wm ——2 — + 


Define the fields and size of the Routine Begin DST record. 
IELD OSTERTNBES FIELDS = 


1 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
' 
: byte 
: 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
F 


LITERAL 


DSTSV_RTNBEG UNUSED = [ 3. v.(Q, 7) 2, 


Unused--Must Be Zero 
This re is set if this 


JSB or BSB rather 
or CALLG 

The routine’s start add 
and entry point ad 


DSTSVCRTNBEG_NO_CALL = 


DSTSL_RTNBEG_ADDRESS = ( 3, L. J], 


DSTSB_RTNBEG_NAME et 7, &. 2 The count byte of the rou- 
tine’s Counted ASCII name 

TES; 

DSTSK_RTNBEG_SIZE = 8; Byte size of the fixed part of the 


Routine Begin DST record 


ge 29 


the 
art 
2 
cord 


ed 
is 


tha 
a CALLS 


nstruction 


ress 
dress 


— — — — — — — — — —— 
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— 
i 
i 
i 
i 
i 
i 
i 
' 
i 
i 
— 
i 
F 


byte 
byte 
byte 
long 


THE ROUTINE END DST RECORD 


The Routine End DST Record marks the end of a routine's scope in the 
DST. It also contains the byte Length of the routine’s code. (Note 
that Routine End DST records must be omitted for Language MACRO but 
are ey | for all other languages.) This is the format of the 
Routine End DST record: 


oo SHC SSDP Se BeBe Be ese See ern nee SE MBOSe SOT eee eae Bese mane mr ame owe * 


DSTSB_LENGTH (= 6) ‘ 


ù ki re ern 


DSTSB_TYPE (= DSTSK_RTNEND) ' 


Fee ee eee eee ee ee sees sees eee eeeeeeeseoeseeeeesoeeeeasoesasesoooeoon + 


: Unused (Must Be Zero) ' 


Feeeoeecoeooeeeoeeeeeeeeeeeeeeeeeoeeeeeeeeeeoeeeeeoceeeeeseeseeseaeeces > 


' DSTSL_RTNEND_SIZE ' 


Pewee eeoeoeeseeeeooeeeeeeeeooeoeoeeoeooeoeeeeeeeeeeoesoeeeeseeeeeececece + 


Define the fields of the Routine End DST record. 


IELD OSTSRTNEND FIELDS = 


PS TSL_STNEND SIZE =(€3, tL. J ! The length of the routine in bytes 


— — — — — — — — — — — —— —— —— — — — — — — — — —— —— —— — — 
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LEXICAL BLOCK DST RECORDS 


e oint tha 
a block does not. Hence BEGIN-END locks 8 BLISS 23 PL/I are blocks 
and so are Paragraphs and Sections in COBOL. Subroutines, functions, 
and procedures, on the other hand, are ‘‘routines’’. 


Blocks and routines do have one thing in common, however. Both define 
syntactic units within which other symbols can be defined. The pur- 
pose of representing blocks in the DST is to define the scopes they 
28 and to give the address ranges of the corresponding bodies 

° 


A lexical block is represented in the Debug Symbol Table by a pair 

of DST records, namely a Block Begin DST record which is matched with 
a later Block End DST record. ALL DST records between the Block —— 
and the Block End DST record represent the symbols that are declare 

in that lexical block or in nested routines or blocks. Nested blocks 
are represented in the DST by properly nested Block-Begin/Block-End 
pairs. Routines and blocks may freely be nested within one another, 
veins the appropriate proper nesting of the corresponding Begin and 
End OST records. 


The start address of a block's code is given in the Block Begin DST 
record and the byte length of that code’is given in the Block End 
DST record. The name of the block is given in the Block=Begin record. 
If a block has no name (which is common for BEGIN-END blocks), the 
null name is piven (the name of Length zero). Blocks with null names 
cannot be explicitly referenced in DEBUG, but Line numbers within such 
blocks can be used to specify breakpoint locations or symbol scopes. 
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eee — — —— — — — 
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1 
' 
1 
] 
] 
1 
1 
! 
1 
: 
: byte 
byte 
; byte 
: Long 
; byte 
i var 

q 
1 
4 
1 
J 
J 
1 
| 
1 
' 
1 
F 


THE BLOCK BEGIN DST RECORD 


t 


pegress. It must be matched by a 


he associated scope. 


Bloc 
This is the format of the Block Begin DST record: 
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The Block Begin DST Record marks the — Lexical block and 
his record contains the 


bl ock® $ name and start 


End DST record later in the 


eeeeee * 


DSTS$B_LENGTH 


$wmmmmmmeweeeewewoeooeeeeewceeesceewoeesececccccoceecocccccccecs} 


DSTSB_TYPE (= DSTSK_BLKBEG) ' 


4 


DST$B_BLKBEG_UNUSED 


24 


DSTSL_BLKBEG_ADDRESS 


— 


T 


DSTS$B_BLKBEG_NAME 


Geeeeeeesooesesosesouesessosesooooseseoeoo sSeeee Seve tw er ee ee eee ee 


The Block's Name in ASCII 
(The name's length is given by DST$B_BLKBEG_NAME) 


err 


ES; 


—RR 


i Define the fields of the Block Begin DST record. 
FIELD DSTSBLKBEG_ FIELDS = 
DST$B_BLKBEG_UNUSED 


DST$L_BLKBEG_ADDRESS 
DST$B_BLKBEG_NAME 


oy — Be Zero 
he block's start address 
the count byte of the block's 
Counted ASCII name 
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byte 


THE BLOCK END DST RECORD 


The Block End DST Record marks me end of a lexical block's scope in 
the DST. It also contains the erte ee of the block's code. This 
fs the format Mot the Block End DST record 


=e eS 
Ee necnececnnenn DSTOBL TYPE (© O8TK_BLKEND) TTT 
— PT, tee Rte Rn nt BS TN a — 
a aE ⏑ — 


Define the fields of the Block End DST record. 


FIELD DSTSBLKEND_FIELDS = 


$s TOL OLKEND_SIZE =(€3, L. J! The byte length of the lexical block 


1 
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DATA SYMBOL BST RECORDS 


Data symbols are represented in the Debug Symbol Table by data DST 
records which come in 2* varieties. ALL such DST records give 
three pieces of information about each symhol: the data type of the 
dim on fe the value or address or the symbol, and the name of the 
symbol. 


The Standard Data DST record is the simplest form of data DST symbol 
record and is used for most arereery atomic data objects. It repre- 
sents the data type by a one-byte VAX Standard Type Code. It repre- 
sents the value or address of the —— by a simple five-byte encoding 
capable of specifying 32-bit Literal values, absolute addresses, reg- 
ister locations, and addresses computed as offsets from a register, 
possibly including indirection. It is also possible to specify that 
the computed address is the address of a VAX Standard Descriptor for 
the data symbol. Finally, the name is represented as a Counted ASCII 
character string. 


There are several reasons why a Standard Data DST record may not be 
adequate to represent a data symbol. First, the symbol's data type 
may be too complicated to ——— by a one=byte type code. In this 
case, one of several available escape mechanisms must be used so that 
expanded type information can be included in the symbol's DST informa- 
tion. Second, if the symbol is a literal (a named constant), its 
value may be too large to fit in one longword. In this case, an ex- 
panded value specification must be used. And third, if the symbol is 
a variable, its address may be specified by a more coupt cated compu- 
tation than can be represented in the Standard Data DST record. In 
this * an escape to a more complicated value specification must 
used. 


Expanded type specifications come in three main forms: Descriptor 
Format DST records, seperate Type Specification DST records, and 
various specialized DST records that handle various special kinds 
of data types such as record structures, enumeration types, and 
BLISS structures. 


Descriptor Format DST records are used when the data object must be 
described by a VAX Standard Descriptor and has a static address. 

packed decimal deta cbject, for xamp le must be described by a 
descriptor that specifies the object's length and scale factor. If 

a desc”iptor exists in user memory at run-time, the Standard Data 

OST record can be used, but otherwise it is necessary to include the 
Gece ipser directly in the DST within a Descriptor Format DST record. 
These DST records are used for all static arrays and other data objects 
that can be described by VAX Standard Descriptors. 


For data types that can be described by neither one-byte type codes 
nor VAX Standard Descriptors, a Separate Type Specification DST record 
mst be used. In this oe the DST record's t ee field indicates that 
the type specification is found is a separate DST record which imme- 
diately follows the present DST record. The DST record that follows 
must be a Type Specification, Record Begin, or Enumeration Type Begin 


| 
| 


| 
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DST record. These records can describe all data types supported by 
DEBUG in full detail. 


As mentioned above, the third data type ‘‘escape'’ mechanism is to use 
one of a number of pore ret ieee DST records that describe data symbols 
of gpec tat kinds. BLISS structures and fields, for example, are de- 
scribed by special DST records, as are enumeration type elements. 
These DST records will not be further described in this section; they 
are described elsewhere in this definition file. 


Expanded “Value Specifications'’ must be used for data — whose 
values or addresses are too long or too complicated to be described 
by the Standard Data DST record. A eee constant, for example, 
has too large a value (8 bytes) to fit in a Standard Data DST record. 
A “based variable’’ in PL/I may require a complicated computation or 
even a call on a comp{ Ler-generated thunk to compute the variable's 
address. for these and other cases, a Trailing Value Specification 
DST record must be used. Such a record includes a Value Specifica- 
tion which may be arbitrarily complex. 


Trailing Value Specification DST records are sometimes used to speci- 
fy both type and address information. An array with dynamic array 
bounds, for instance, must be described in the DST if no descriptor 
exists in user memory at run-time. A —8 Value Specification 
can be used to compute the entire descriptor for such an array at 
DEBUG-time. The descriptor then gives both the array address and 
type information such as the element type and the array bounds. 
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THE STANDARD DATA DST RECORD 


The Standard Data DST record is used to describe most simple scalar 
data objects such as integers, floating-point numbers, and complex 
numbers. The data type is represented by the one-byte VAX Standard 
Type Code in the DSTSB_TYPE fieid. The value DSTS$K_BOOL is also 
accepted; it denotes that the data symbol is a Booléan variable or 
value which is TRUE if the low-order bit is set and FALSE otherwise. 


The value specification in the Standard Data DST record indicates 
the symbol’s value or address or how to compute the symbol's address. 
The details are found below. 


This is the format of the Standard Data DST record: 


Pee eeeeees coe eee eeeeeeeeeeeeoaneoesooaon eseecoeee Se eeeeeneeneaeaeaeo eeeceoen} 


byte ‘ DSTSB_LENGTH H 
byte | DSTSB_TYPE : 
$e enn om ae See eneceeeeeotowoccos}o seeecee tem esomwmoemn areca ae om 
byte ‘ DSTSV_REGNUM ‘ DISP INDIR H DST$V_VALKIND H 
Long ‘ DSTSL_VALUE H 
byte : DSTSB_NAME H 
we eet en ae TOS te BB moot eR BBO BOO EEO mE MODE DO MDT mB eB enema DO Bee ee wm + 
var H H 
: The Symbol Name in ASCII ' 
(The name's length is given by DSTSB_NAME) 
e eeecoeeeoeoe See eee oeoeroeoooeoeo eseececoeeoee — aaa ewe e 2 — ——— > 


Define the fields of the Standard Data DST record. These fields are also 
used in many other DST records of similar formats. 


ee ee ee ee ee ee —— — 


as a displacement off a register 
} specified in DSTSV_REGNUM 
DSTS$V_REGNUM = € 2, V_(4,4)],! Number of register used in displace- 
: ment mode address in 
DSTS$L_VALUE = f 3. tL. J, ! Value, address, or bit offset 
DSTS$B_NAME e B. J ! Count byte of the symbol name field, 
: a counted ASCII string 


IELD OSTOs TOF ELSS J 
DSTSB_VFLAGS = » & z: ValuenF tags (access information) 
DSTSV_VALKIND = - V_(0,2)],! How to interpret the specified value 
DSTSV_INDIRECT = ° v7 (25 J], ! Set if address of address is produced 
: by indicated computation (do an 
: indirection to compute address) 
DSTS$V_DISP =( 2, v.(3) J, Set if content of DSTSL_VALUE is used 
' 
I 


| F 
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TES; 


Define all special values that wey appear in the DSTSB_VFLAGS field. If one 
of these values sopeers in that field, the DSTSL_VALUE field has some speciat 
meaning indicated the special value. In * cases, the DSTSB_VFLAGS sub- 
fields have no meaning. Not all of these special values may appear in a 
Standard Data DST record (see the comments below), but they are all Listed 

' here for completeness. Note that these values (with one exception) all have 
! the top four bits set--hence ney cannot be normal VFLAGS values since the 

! REGNUM field cannot contain 15 (indicating the PC) in a normal VFLAGS value. 


ITERAL 
DSTSK_VFLAGS_NOVAL = 128, !A leg which indicates that no value 
s specified, i.e. the object 
being described is a type. This 
value oer only appear in a Record 

—* DST record. 

This value is DSTSB_VFLAGS signals a 
data item that was never 
allocated (and hence has no 
address). For example, PASCAL 
does not allocate variables 


( cevavavecasavacace 


DSTSK_VFLAGS_UNALLOC = 249, 


that are not referenced. 
DSTSK_VFLAGS_DSC = 250, This value in DSTSB_VFLAGS signals a 

Descriptor Format DST record 
DSTSK_VFLAGS_TVS = 251, This value in DSTSB_VFLAGS signals a 

Trailing Value Spec DST record 
DST$SK_VS_FOLLOWS = 253, Value Specification Follows (allowed 

only in a Trailing Value Spec) 
DSTSK_VFLAGS_BITOFFS = 255; 


A flag —*— that DST$L_VALUE 
contains a bit offset (used 
only for record components) 


! Provided the DBGSB_VFLAGS field does not have one of the above agec tot values, 
! the DBG$V_VALKIND field indicates what kind of value or address is computed | 
: by the value computation. The possible values of this field are defined here. 

i 


ITERAL 

DSTSK_VALKIND_LITERAL = 0, ! DSTSL_VALUE contains a Literal value 

DSTSK_VALKIND_ADDR = 1, ! Computation produces the address of 
' the data object 

DSTSK_VALKIND_DESC = 2, ! Computation produces the address of a 
: VAX Standard Descriptor for the 
} data object 

DSTSK_VALKIND_REG = 3; } Value is contained in the register 


whose number is in DSTSL_VALUE 


If the DSTSK_VFLAGS field does not contain one of the special values listed 
above, then the computation that produces the value or address of the data 
object proceeds as follows: 


1. If the VALKIND field contains DSTSK_VALKIND LITERAL, the symbol is a 
constant whose value is given by the DSTSL_VALUE field. Such constants 


—ñ— — — ——— 
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can be up to 32 bits long. 


2. If the VALKIND field contains DSTSK_VALKIND_REG, the symbol is a vari- 
able bound to a register. The regiSter number of that register is 
given by the DSTSL_VALUE field. 


3. Otherwise, the symbol is a variable with a non-register address. To 
compute that address, the DSTSL_VALUE field is picked up. 


4. If the DSTSV_DISP bit is set, the contents of the register whose reg- 
ister number is given by the DSTSV_REGNUM field is added to the value 
picked up from the DSTSL_VALUE field. 


5. If the DSTSV_INDIRECT bit is set, the address computed so far is treated 
as the address of a pointer that points to the actual data object. In 
other words, an indirection is done. 


6. If the value of the VALKIND field is DSTSK_VALKIND_ADOR, the address 
computed so far is treated as the address of the data object. 


7. If the value of the VALKIND field is DSTSK_VALKIND_DESC, the address 
computed so far is treated as the address of a VAX Standard Descriptor 
for the data object. The actual address of the object, along with its 
other attributes such as type and size, must therefore be retrieved 
from that descriptor. 


As this description indicates, aoseretesy complicated address computations 
can be specified in the Standard Data DST record. fFor.example, the address 
of the second formal pecemeter to a routine, passed by reference, can be 
described by making DSTSV_REGNUM = 12 (for register AP), DSTSL_VALUE = 8 
(to indicate an offset of 8 Bytes from AP to get at the second longword in 
the argument vector), DST$V_DISP = 1 (to indicate that DSTS$SL_VALUE is to be 
treated as a displacement off AP), and DSTSV_INDIRECT = 1 (to indicate an 
indirection since the argument is passed by reference). OSTSV_VALKIND = 
DSTSK_VALKIND_ADDR in this case. If the parameter were preere by descrip- 
tor, Rowever, DSTSV_VALKIND should be DSTSK_VALKINKD_DESC, with all other 
fields having the same values as in the pasSed-by-reference case. 


El Dee Re De te ted ed ee ed oe ee te ee te te te te ee —— 


1 
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THE DESCRIPTOR FORMAT DST RECORD 


1 
1 
1 
The Descriptor Format OST record is ysed when a VAX Standard 
\ Descriptor must be included in th : DST for a static $y ymbol. It 
: includes the descriptor directly in the DST —* right after 
: the name field. This record is mee gg identical to the 
: Standard Data DST record except that the DST$B Fae fHetd has 
‘ the special value gate VFLAGS_DSC and the DSTSL VALUE field is 
: a relative byte offset fo the VAX descriptor latér in * ——— 
This is the format: ; 
J 
' ¢ pet ewe ere e mem mmm em eee eee ew me meee mmo cwm een ee merece maasemaoanat 
: byte ‘ DSTSB_LENGTH ' 
> eceeeeooeeewoeooocooccowceoeeescoeeooceccoececccccoceccccocccess} 
: byte : DSTSB_TYPE H 
byte : DST$B_VFLAGS (= DSTSK_VFLAGS_DSC) ! 
! long DSTSL_DSC_OFFS we 
byte i DST$B_NAME (also DSTS$A_DSC_BASE) i 
i var H ' 
} ' The Symbol Name in ASCII ' 
} (The name's Length is given by DST$B_NAME) 
a 
' Femwweoomooooooonpoooooe See rrr woooooon+ H 
: Long ! DSCSB_CLASS ‘ DSCSB_DTYPE : DSCSW “LENGTH ¢ as 
i Long : DSC$A_POINTER : 
i var H H 
‘ Other VAX Standard Descriptor Fields ‘ 
depending on the descriptor class 
! 
‘ — w ewe wero m ome moe — ree Ome Ee mee Seer eeeeee se eee eee esses eesecoe + 
' 
' 
i 
Define the fields of the Descriptor Format DST record. 
FIELD OSTapse FIELDS = ‘ 

BSTSL st ores «© f 3.4. }. Offees | in i bree be to CASE 

DSTSA_DSC_BASE =({ 7, A_ ] ; — torte * this loc- 


ation + DST$L_DSC "OFFS 
TES; 
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H Note that the address of the descriptor is computed as follows: 
i DST_RECORDCDSTSA_DSC_BASE] + .DST_RECORDCDSTSL_DSC_OFFS) 
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— ee te te te te te te te te et ee eee eee ee 


i 
. 
J 
i 


byte 
byte 
byte 
long 
byte 
var 


var 


THE TRAILING VALUE SPECIFICATION DST RECORD 


The Trailing Value Specification DST a is used when an expanded 


value specification is needed to com a data symbol's value or 
address. It includes a Vaiue Specif Sarton directly in the DST rec- 
ord right after the nane field. — record is betse vitat identical 
to the Standard Data DST record except that the DSTSB_VFLAGS a has 
the special value DSTSK_VFLAGS_TVS | the DSTSL_VALUE field i 

relative byte offset to “the Value Specification Sy in the record. 
This is the format: 

te tere me ree m erm er ee mene we —4 

‘ DSTSB_LENGTH H 

H DST$B_TYPE H 

H DSTSB_VFLAGS (= DSTSK_VFLAGS_TVS) H 

: DSTSL_TVS_OFFSET — 
DSTSB_NAME (also DSTSA_TVS_BASE) <a 
The Symbol Name in ASCII 
(The name's length is given by DSTSB_NAME) 
——— — — ——————— a — 4 
H 14224 
DST Value Specification 

} en —————— ——————————— ————————— — a > 


Define the fields of the Trailing Value Specification DST record. 


fo 


FIELD OS TE TVS FIELDS = 


DSTSL_TVS_OFFSET = 3. L_ J, 
DSTSA_TVS_BASE =(€7, A. ] 
TES; 


Offees | in sn Srtet 36 to toast "2 Value Spec 


——— Value Speen starts at this 
location + .OSTSL_TVS_OFFSET 


: pty Ben thet the address of the trailing Value Specification is computed as 


DST_RECORDCDSTSA_TVS_BASEJ + .DST_RECORDCDSTSL_TVS_OFFSET) 


— — — 


DSTRECRDS.REQ; 1 


' Also ngte that Va 
: later n this def 


ined 
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pect cat tons are described in a separate section 
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THE SEPARATE TYPE SPECIFICATION DST RECORD 


The Separate Y 
of the symbol being described is too complex to be Congr ined by 
ype code or a VAX Standard pescrigtor This DST 
$ cation, Record Begin, 


a Trailing Value Specification if 22 to describe the symbol's 
value or address. This is the format of the 


en eee ewe ewer een eee cores enw ec eee meee sme c ecm ecaes sass eoee eeeeeoe wows mand 


— RT 
— — 
Tn ate SE Re ; 
i EIN — yao 
— —— — — 
var 


The Symbol Name in ASCII 
(The name's Length is given by DSTS$B_NAME) 


 oeeeccccccne 


var 
A Trailing Value Specification or nothing, 


depending on the value of DSTSB_VFLAGS field 


} cocccccccece @ cc cccecccccs 


— eo ee ee ee See eee rem ewe wwe SMSO OO ee we wm oe * 


— | 


M 
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DST VALUE SPECIFICATIONS 


A DST Value Specification specifies the value or address of some ine oe 
Value Specification can occur in a number ef places in the Debug 
Table. The simplest forms of Value Specifications occur in the Standard 


$s 
Format DST records where a VAX Standard Descriptor is included in the 
DST record to give more —— address information (and type informa- 
tion pecif mple five- 
byte Value Specification of the beginning of the record which *8* to 
at more 
e Specification can be any kind of Value Specification, in- 
cluding the most general forms. 


In addition, Value Specifications — | occur in a number of Type Speci- 
fications. In these cases, they typically generate values (as opposed 
to addresses), such as subrange bounds for a subrange data type, or they 
enerate full VAX Standard Descriptors in order to specify some sort of 
ata type, such as a dynamic array. 


eld i d S_R 
DST$SV_VS_DISP, DSTSV_VS_INDIRECT, and DSTS$K_VS_VALKIND. “This is also 
described in detail Tn the Standard Data DST Record section above. 


STANDARD VALUE SPECIFICATIONS 


As indicated above, if the DST$B_VS_VFLAGS field does not have a special 
value, the Value Specification is a Standard Value Specification and has 
the following structure: 


dose cman ec S ewe nero + 


i byte | DST$V_VS_REGNUM ! DISP { INDIR | SV_VS_VALKIND } 


$ewoesce ween oe soem once — enema ane ees 


i tong } DSTSL_VS_VALUE ' 


boom eee eee ee nese ree ete =e = eer — ween ere ewe eee wm ee — etre te eee ee wee + 


w 
3 
c 
Ww 
e 
bee 
> 
o 
4 
~~ 
A 
~ 
@ 
— 
[-% 
zs ~~ 
& 
wr 
° 
2 
@ 
°o 
— 
7 
zs 
@ 
Ww 
ao] 
oD 
o 
~~ 
ao 
~ 
< 
a 
— 
— 
@® 
ww 
L~J 
nm" 
~ 
wn 
xn 
‘ 
<= 
mn 
E 
> 
a 
nm 
a 
4 


i Define the fields of the various kinds of Value Specifications. Also define 
: the declaration macro. 


FIELD DST$VS_HDR_FIELDS = 


DSTS$B_VS_VFLAGS = f 6. B_ i: ! Value-flags (access info) 
DSTSV_VS_VALKIND = » V.(0,2) J, ! How to interpret the value 


DSTRECRDS.REQ; 1 16-SEP-1984 16:49:18.30 Page 45 


not counting the VFLAGS 
and VS_LENGTH fields 
Allocation Tndicator | 
Location of Materialization 
Specification 


DST$B_VS_ALLOC 
DSTSA_VS_MATSPEC 


TES; 


wu 

ore 

fw 

.* 

>@w 

a 

ww 

. 


DSTSV_VS_iINDIRECT = ° —56 }: ! Set to get indirection 
DeTSV- VS_DISP = » V.05) J... ! Set for register eteplecenent 
DST$V_VS_ nt» = » Vi44,4) J, ! Register number for —— 
IMCISCut A —— }: ' Value, address, or bit offset 
DSTSL_VS “pst OFFS *t t,t, Je Ott set in bytes te to iar 
: from 
DSTSA_VS_DSC_BASE “tt, & 3, : Descriptor | erie at this loca- 
: * DSTSL_VS_DSC_OFFS 
DSTSL_VS_TVS_OFFSET *t t,t. 3, — tn on Srtee a vase ee 
DSTSA_VS_TVS_BASE 2 & *@ te » — Spec starts a ths of S27 | 
DST$W_VS_LENGTH =C€1, 0, ], Length of Value Spec-in Bytes | 


DSTSVAL_SPEC = BLOCKC,BYTE) FIELD(DSTSVS_HDR_FIELDS) 2%; 
' The eae Literal values may appear in the DST$B_VS_ALLOC field. | 


 ostsk _VS_ALLOC_STAT 21. ' Value is static 
DSTSK_VS_ALLOC_DYN = 2; ! Value is dynamic 


! Define the fields of the Materialization Specification. Also define the 
declaration macro. 


FIELD vag FIELDS = 


DSTSB_MS_KIND =({0,8.], ! The kind of value produced 
DST$B_MS_MECH ee a, [ }: ! The mechanism whereby produced 
DST$B_MS_FLAGBITS = $ a. we ! Flag bits 
DSTSV_MS_NOEVAL = - V.(0) J, ! Purpose of this bit not clear 
hh yf = ¢° v.41) J, ! Include ** q = call 
DSTSA_MS_MECH_SPEC = ‘ . AL }- ' Location of Mechanism $ 
DSTSL_MS_MECH_RTNADDR = ([ 3, L- ! Routine address for call. 
: compiler-generated thunk 
TES; 
| 


DSTSMATER_SPEC = BLOCKL,BYTE] FIELD(DSTSMS_FIELDS) 2%; 


1. : The value is a byte address 
i The value is a bit address (a Longword 
i byte address plus a longword bit 


t 
wow 
— 
— 
RP 
o 
J 
zz 

“uw 
~ 


— — — — — — —— 
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offset from the byte address) 


{ 
DSTSK_MS_BITOFFS = 3, ! The value is a bit offset (normally a 

; bit offset from the start of a 

} record--used for record components) 
DSTSK_MS_RVAL = 4, : The value is a Literal value (constant) 
DSTSK_MS_RES = 5, ! The value is a register number (the 

: address is a register address) 
DSTSK_MS_DSC = 6; ! The value is a VAX standard descriptor 


|: The following values may appear in the DSTSB_MS_MECH field. 
LITERAL 


DSTSK_MS_MECH_MIN = 1, ! Minimum code 
DSTSK_MS_MECH_RTNCALL = 1, ! Routine call on a compiler- 
; porar ates thunk 
DSTSK_MS_MECH_STK = 2, ! DST Stack Machine routine 
JMS_ JRTN_ = 5, ! Same as ‘'1"' but no FP passed in 
DSTSK_MS_MECH_MAX = 3; ! Maximum code 


| 
DSTSK_MS_MECH_RTN_NOFP 


1 
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DESCRIPTOR VALUE SPECIFICATIONS 


If the DSTSB_VS_VFLAGS field has the special value DSTSK_VFLAGS_DSC, 
this is a DeScriptor Value Specification. Such a Value Specification 
contains an offset relative to the end of the Value Specification that 
points to a VAX Standard Descriptor later in the same DST record. That 
descriptor then contains the actual address that the Value Specifica- 
tion seeks to specify. This is thus the format: 


foe nuwe eeceececon cece nme enone — e een eoaerecee — Bee weoran nase arace h 
byte : DSTSB_VS_VFLAGS (= DSTSK_VFLAGS_DSC) 
long ! DSTSL_VS_DSC_OFFS — 

ù————— ——————— 
vert DSTSA_VS_DSC_BASE 

Other Fields in DST Record a 

— — — ee een own ose oe mene meee mee SOS Reena wee ee meee eee ee > ' 
ver — 

VAX Standard Descriptor Giving Symbol Address | 

o- wwe eee ewer weer een ene a a es + 


The address of the VAX Standard Descriptor is computed as follows: 
DSC_PTR = VS_PTRCDSTSA_VS_DSC_BASE] + .VS_PTRCDSTS$L_VS_DSC_OFFS); 


— — — — — — — — — — — — — — — —— —— — — — — — — — 


ee ee ee ee ee ee —— —— 
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byte 
Long 


var 


var 
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TRAILING VALUE SPEC VALUE SPECIFICATIONS 


If the DSTSB_VS_VFLAGS field has the special value DSTSK_VFLAGS_TVS, 
this is a [reiting Value Spec Value Specification. Such"a Value 
Specification contains a pointer relative to DSTSA_VS_TVS_BASE that 
points to another Value Specification Later in the same DST record. 

his second Value Specification is —— of the most general and 
powerful form of Value Spec) tices ton. namely the VS-Follows Value Spec- 
ification. In effect, the te ag Value Spec format is a —*326 
Value Specification (small enough to fit in a Data DST Record) which 
points to a larger Value Specification elsewhere in the same DST record. 
his larger Value Specification can be arbitrarily large and complex 

in order to do whatever computation is necessary to obtain the desired 
value, address, or descriptor. 


This is the format of the Trailing Value Spec Value Specification: 


Geeroeoeeoeeoecan See een ene e eee ee eS em ee wewereroner moana e (eee ee ee ee ee ee a ee eS + 
t DSTSB_VS_VFLAGS (= DSTSK_VFLAGS_TVS) H 
: DSTSL_VS_TVS_OFFSET — 
+ eeecoeee eeeoeeceon eer rere e rece aenr wt we ec ee eee ete =e — — — — — — — — — — — — — — — — (oO oe em ee om me : 
‘ DSTSA_VS_TVS_BASE ' 
; Other Fields in DST Record | 
—— ——— . 4 
: 14224 
The Trailing Value Specification 
: (Normally a DSTSK_VS_FOLLOWS Value Specification) 
‘ eeoeece weer wr wr wr wens wm ee ee ewe BD He ee em em — Ome BO ——— —— — De em wee M 


The address of the Trailing Value Specification is computed as follows: 
TVS_PTR = VS_PTRIDSTSA_VS_TVS_BASEJ + .VS_PTRCDSTSL_VS_TVS_OFFSETI; 


F 
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VS-FOLLOWS VALUE SPECIFICATIONS 


if the DSTSB_VS_VFLAGS field has the special value DSTSK_VS_FOLLOWS, 
this is a VS=Follows Value Specification. This is $he most general 
and powerful form of Value Specification. The spec fication itself 
can be arbitrarily long, but it can also do an arbitrarily complex 
computation in order to compute the desired value, address, or de- 
scriptor. This is the format of the VS-Follows Value Specification: 


ote aaaennnanPSTSBLUS.VPLAGS. (2OST#R=VS_FOLLOWS) TT | 
word } DSTSW_VS_LENGTH 
pa NI TET | 
var DSTSA_VS_MATSPEC | 
; A Materialization Specification 
— —— — — 


A VS-Follows Value Specification contains a Materialization Specifica- 
tion which indicates how the value is materialized. This specifica- 
tion indicates what kind of value is being produced, by what mechanism 
it is pretuces. and in detail how it is produced. {t also contains 
some flag bits. 


bit address (a byte address followed by a 32-bit bit offset), a bit 
offset (relative to the start of a record--used only for record compon- 
ents), a literal value (a constant or "‘R-value"’), a register address, 
or an actual VAX Standard Descriptor. VAX Standard Descriptors are 
mainly produced by Value Specification within Type Specifications where 
a descriptor must be built to describe a data type such as an array 
type with run-time subscript bounds. 


| 

The kind of value being produced can be a 35-bit byte address, a 64-bit | 
re 

| 

| 


Values can be produced by two mechanisms. One is a routine call on a 
compiler-generated thunk. In this case, the compiler generates a rou- 
tine in the object code which when called produces the desired value. 
The address of the routine is specified in the Mechanism Specification. 
The other mechanism is a DST Stack Machine routine. The DST Stack 
Machine is a virtual machine which DEBUG emulates. To use it, the com- 

iler generates code for this virtual machine which, when executed at 
EBUG-time, produces the desired value. The DST Stack Machine form of 
Mechanism Specification constitutes the most general and powerful form 
of value specification supported by DEBUG. 
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1 
i 
i 
i 
1 
i 
1 
i 
1 
i 
‘ 
: 
‘ 
i 
i 
: byte 
: word 
: byte 
! byte 
byte 
i byte 
long 
i 
i 
i 
i 
' 
i 
‘ 
i 
i 
i 
i 
$ 
i 
1 
i 


CALLS ON COMPILER-GENERATED THUNKS 


The Routine Call Mechanism Specification specifies the address of a 
compiler-generated routine (a thunk) which DEBUG can call to perform 
the desired value computation. This form of Mechanism Specification 
must be used for PL/I] ‘BASED’’ variables since the address of such a 
variable can depend on the value returned by a user-defined function. 
In this case, the Mechanism Specification consists of a single longword 
giving the address of the compiler-generated thunk to call. 


This is the format of the whole Value Specification when the Routine 
Call Mechanism Specification is used: 


H DSTSB_VS_VFLAGS (=DSTSK_VS_FOLLOWS) H 
' DSTSW_VS_LENGTH (= 8) ' 


— emer neem ee roo men mmo e Sw ae a oe 92 ee ee oe ow ee Or on me ee oe ey ee cP ab ae ay ae a a oe ae + 


: DSTSB_VS_ALLOC (= DSTSK_VS_ALLOC_DYN) i 


tances wae et eee cae seone ocean See Monae eee we ume Se Sues See ee oe ewe oo 


DST$B_MS_KIND 
DSTSB_MS_MECH (= DSTSK_MS_MECH_RTNCALL ; 


bere nwo nes oe eererew e-— — re me ee em on oe oe a ee ob em me ee oe ee me (OF SD ce + 
: DST$B_MS_FLAGBITS i 


; DSTSL_MS_MECH_RTNADDR ; 


¢oceeocean eee eeeoeteee SSS 22S SSS SS SS SSS SS — S222 222202 eeweoeerroewrrerewe2e = + 


The called routine is passed the address of a vector of register values 
as its one argument. This vector contains ali register value for the 
scope (call frame) in which the symbol having this Value Spec tt heat ten 
is declared. The vector contains the values of registers RO - R11, AP, 
FP, SP, PC, and PSL in that order. The routine is allowed to use all 
such values in its computations, but is not allowed to change the con- 
tents of the register vector. in addition, the routine is passed the 
value of FP (the Frame Pointer) in register R1. 


The value of the routine should be returned to DEBUG in register RO. 


The DSTSV_MS_DUMARG bit should be set in the DSTSB_MS_FLAGBITS field if 
the called routine expects to return a value longer than one lonoword. 
If DSTSV_MS_DUMARG is set, the address of an octaword (four-longword) 
buffer is passed as the first argument to the called routine with the 
expectation that the routine’s value will be returned to this buffer. 
The address of the register vector is then the second argument. 


— — — — — — — — — — 
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byte 
word 
byte 
byte 
byte 
byte 


var 


THE DST STACK MACHINE 


The DST Stack Machine is a virtual machine emulated by DEBUG. This 
machine can push and pop values on a stack and can perform a variety 
of arithmetic and logical operas tone, It can also call compiler- 
generated thuiks. The DST Stack Machine is used when a value must be 
computed at DEBUG-time and the Standard Format Value Specification is 
not adequate and a compiler-generated thunk to do the whole computation 
seems undesirable. In such cases, the compiler can generate a Mecha- 
nism Specification which consists of code for the Stack Machine. At 
DEBUG-time, when the value in question is needed, DEBUG will interpret 
this code until the STOP instruction is encountered. The value that 
—— = top of the Stack Machine stack is then taken to be the 
esired value. 


The format of the whole Value Specification when a DST Stack Machine 
Mechanism Specification is used is as follows: 


— ene mere mene wre coaece Renee aes moe eae — ear aanean enero + 


DST$B_VS_VFLAGS (=DSTSK_VS_FOLLOWS) } 


Penne wearer e awn nwo me = — eaoeoecee Ser eecocecee nee ae — 2— 22 


DSTSB_MS_KIND 


ewe mnwaer nnn ose mn eeeeeeoeoeeecen Serer ene enn esas sana e BES nnw naam e + 


DSTS$B_MS_MECH (= DSTSK_MS_MECH_STK) 


— — ù—— ee cee ee esere seer esene cen ee eocee + 


DSTSB_MS_FLAGBITS i 


cee ee ù— — ——— ———— —— ——— ——— — ——— — ————— —————— ————— 22 


DSTSA_MS_MECH_SPE ' 
DST Stack Machine Routine 


Pe 


eocre- fe ef we eee weer emote mmm wm meow oeme oe Smee emma wer w ens wre ree eo eee ene eece ee} 


Here the DST$B_VS_ALLOC field should have the value DSTSK_VS_ALLOC_DYN 
if any kind of address is computed and DST$K_VS_ALLOC_STAT if a Liferal 
value (a constant) is computed. The need for this field is not clear 
since DEBUG ignores it at present. 


The stack upon which the DST Stack Machine operates consists of 256 
locations where each location is a longword. The stack grows toward 
smaller addresses and shrinks toward larger addresses; in this regard 
it is Like the VAX call stack. A DST Stack Machine Routine consists 
ofa sequence of Stack Machine instructions ending in a STOP instruc- 
tion (DSTSK_STK_STOP). When the machine stops, the top location or 
locations on the stack constitute the value of the routine. The length 
of the value is determined by the DSTS$B_MS_KIND field. 
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: The DST Stack Machine supports the instructions tabulated in the re- 

: mainder of this section. Each instruction consists of a one-byte op- 

° code followed J zero or more operand bytes, Copens ine on the op-code. 
: In this description, the “‘top’’ stack cell refers to the most recently 

: pushed ceil still on the atest and the ‘'second’’ cell refers to the next 
: most recently pushed cell still on the stack. Each cell contains a 

: Longword value. 

1 


Define the Push Register instructions. These instructions push the indicated 


ii register value on the Stack Machine stack. The register values are taken from 


3 the scope (call frame) of the symbol for which the value is being computed. 


“LITERAL 


DSTSK_STK_LOW = 0, ! Lower bound for range checking 
DSTSK_STK_PUSHRO = 0, ! Push the value of register RO 
DSTSK_STK_PUSHR1 = 1, ! Push the value of register R1 
DSTSK_STK_PUSHR = ¢° ! Push the value of register R 
DSTSK_STK_PUSHR = 3, ! Push the value of register R 
DSTSK_STK_PUSHR4 = 4, ! Push the value of register R4 
DSTSK_STK_PUSHRS = 5, ! Push the value of register R5 
DSTSK_STK_PUSHR6 = 6, ! Push the value of register R6 
DSTSK_STK_PUSHR7 = 7, ! Push the value of register 87 
| DSTSK_STK_PUSHRB = 8, ! Push the value of register R8 
DSTSK_STK_PUSHR9 =9 ! Push the value of register R9 
DSTSK_STK_PUSHR10 = 16, i Push the value of register R10 
DSTSK_STK_PUSHR11 = 11, ! Push the value of register R11 
DSTSK_STK_PUSHRAP = \¢- ! Push the value of the AP 
DSTSK_STK_PUSHRFP = 15, ! Push the value of the FP 
DSTSK_STK_PUSHRSP = 14, ! Push the value of the SP 
DSTSK_STK_PUSHRPC = 15; ! Push the value of the PC 


} 

| Define the Push Immediate instructions. These instructions are used to push 
! constant values on the Stack Machine stack. The constant value to push comes 
|; immediately after the instruction op-code. for the signed and unsigned in- 
! structions, the value to push is zero-extended or sign-extended to 52 bits 
J as appropriate. In the case of the Push Immediate Variable instruction, the 
: pyte after the op-code gives the byte length of the constant value to push. 
! The constant value to push then follows immediately after that length byte. 
! The constant value is zero-extended to the nearest longword boundary on the 
high-address end and the resulting block is pushed onto the stack. 

L 

| 

| 


ITERAL 


DSTSK_STK_PUSHIMB = 18. ! Push Immediate Byte (signed) 
DSTSK_STK_PUSHIMW = 17, ! Push Immediate Word (signed) 
DSTSK_STK_PUSHIML = 18, ! Push Immediate Longuord (signed) 
DSTSK_STK_PUSHIM_ VAR = 24, ! Push Immediate Variable 

DS T$K_~STK_PUSHIMBU = 25,  ! Push Immediate Byte Unsigned 
DSTSK_STK_PUSHIMWU = 26; ! Puch Immediate Word Unsigned 


! Define the Push Indirect instructions. For these instructions, the top stack 
cell is ed and the one, two, or four bytes at the address given by the 
popped ceil are sign extended to 52 bit and pushed on the stack. for the 


— — — a — —— — — — — — — — — —— — — 
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! unsigned instructions, the value is instead zero-extended to 32 bits and 
_} Pushed on the stack. 


LITERAL 

DSTSK_STK_PUSHINB = 20, ! Push Indirect Byte (signed) 

DSTSK_STK_PUSHINW = 21, ! Push Indirect Word (signed) 
DSTSK—STK_PUSHINL = 3 ! Push Indirect Longword (signed) 
DSTSK_STK_PUSHINBU = e/, ! Push Indirect Byte Unsigne 
DSTSK_STK_PUSHINWU = 28; ! Push Indirect Word Unsigned 


r Detine the arithmetic and logical instructions. These instruction pop the 


! top two cells on the stack, perform the indicated operation on these operands, 
! and push the result back onto the stack. 


lj 
“LITERAL 
DSTSK_STK_ADD = 19, Add=--The top two cells on the stack 
| are popped from the stack and 
added together. The resulting 
sum is pushed onto the stack. 
DSTSK_STK_SUB = 29, Subtract--The second cell on the stack 


' 

i 

i 

i 

i 
! is subtracted from the top cell. 
$ Both are popped from the stack. 
! The resulting difference is then 
: pushed onto the stack. 

DSTSK_STK_MULT = 30, ! Multiply--The top two stack cells are 
! popped from the stack and multi- 
H plied. The resulting product is 
! then pushed onto the stack. 
DSTSK_STK_DIV = 31, ! Divide--The top stack cell is divided 

: by the second stack cell. Both 
! are popped from the stack. Their 
: quotient is then pushed onto the 
' 
' 
i 
i 
i 
i 
i 
i 
i 
i 


stack. 
! Logical Shift--Shift the second stack 
cell by the number of bits piven 
0 
operands and push the s ed 
second cell on the stac 
Rotate--Rotate the second stack cell 
by the number of bits given by 
the top stack cell; pop both 
operands and push the rotated 
second cell on the stack 


by the top stack cell; por. 
k 


| 
DST$K_STK_LSH = 32, 
DST$K_STK_ROT = 33; 


Define the Copy and Exchange instructions. These instructions make a copy 
of the top stack cell or exchange the top two cells on the stack. 


: 
LITERAL 


DSTSK_STK_COP = 34, ! Copy--A copy of the top stack cell 
: is pushed onto the stack 
DSTSK_STK_EXCH = 35; Exchange--The top two stack cells are 


interchanged 
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Define the Store instructions. Following ped op-code, these instructions 
contain a byte which is interpreted as a signed offset into the stack. The 
low-order byte, word, or longword of the top stack cell is stored into the 
byte. word, or longword given by the current stack pointer plus four plus 
the signed offset into the stack. (In short, the offset is an offset from 
the second stack cell.) After that, the top stack cell is popped. These 
instructions permit values to be stored into stack locations other than the 
top or second stack cell. 


io. — te ee — — — —— 


ITE ; 
DSTSK_STK_STO_B = 36, ! Store Byte into Stack 
DSTSK_STK_STO_W = 37, ! Store Word into Stack 
DSTSK_STK_SIO_L = 38; ! Store Longword into Stack 


! Define the Pop instruction. This instruction 2* pops the top stack cell, 
meaning that the top stack cell is removed from the stack and discarded. 


LITERAL 
DSTSK_STK_POP = 39; ! Pop Top Stack Cell 


| 

i 

| Define the Stop instruction. This instruction stops the DST Stack Machine and 
! is required at the end of every DST Stack Machine routine. Whatever value is 
' left at the t 9 of the stack when the Stop instruction is executed is taken to 
! be the value .f the Stack Machine routine. This value may be a longword (a 
: byte address, for example), two Longuords (byte address and bit offset), any 
! size Literal value (an H-F loating literal, for instance), or a full VAX Stan- 
dard Descriptor, depending on the value of the DSTSB_MS_KIND field. 
L 


ITERAL 
DSTSK_STK_STOP = 23; ! Stop the Stack Machine 


! Define the Routine Call instructions. These instructions call a compiler- 
rated routine (a thunk) whose address is given by the top stack cell. 
fore the call actually occurs, the top stack cell is geopes. The value 
! that is returned by the thunk is then pushed onto the stack. 


! The Routine Call instruction works as follows. The address of the thunk to 
! to be called is taken from the top stack cell. The top cell is then popped. 
! The thunk, which is called with a CALL instruction, gets two arguments. The 
! first argument is the address of a vector of register values for the Scope 

' (call fra.e) of the symbol to which this Value Specification belongs. This 
' yecto: contains the values of regteters RO - R11, AP, FP, SP, PC, and PSL in 
' that order; the called thunk is free to read any value it wants from this 

' vector but may not store into it. The second parameter is a pointer to the 
' top of the DST Stack Machine stack after the thunk address has been popped. 
' A Stack Machine routine gan thus compute arguments to the thunk and push them 
! on the stack before pushing the thun address ond call ng the thunk. In 

! addition, the value of FP in the symbols scope is passed to the thunk in 

! register R1. The routine’s value is expected to be returned in register RO. 
! This value is pushed onto the stack. 


i The Routine Call With Alternate Return instruction works this same way except 
! that the address of an octaword buffer (4 longwords) is passed to the thunk 


— — — — 
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! as the first argument, with the register vector being the second argument and 
' the stack address being the third argument. In this cage. the routine value 
! is expected to be returned to the octaword buffer, not in register 20. The 

: whole octaword buffer is then pushed onto the stack. 


LITERAL 
DSTSK_STK_RTNCALL = 40, ! Routine Call ( 
DSTEK STR URTNCALL ALT = rE ! Routine seit id 
= 44; all - 


| 

| 

| ue returned in RO) 
DSTSK_STK_RTN_NOF ' Routine C 


al 
th Alternate Return 
no FP passed in 


! Define the Push Record Address instructions. These instructions push the 

' addr ss of the outer-most or inner-most record structure for which the cur- 
! rent symbol is a record component. They are used for constructing VAX Stan- 
! derd Descriptors on the Stack Machine stack when some part of the descriptor 
! depends on some other component of the same record. In PL/I, for instance, 
! the subscript bounds of an array component of a record may depend on another 
! component of that record. In such cases, the only way to get the address of 
! that other component in the current record is to use one of the Push Record 
' Address instructions. The Push Outer Record Address instruction pushes the 
! address of the outer-most record of which the current symbol is a component 
! while the Push Inner Record Address instruction pushes the address of the 

: inner-most record of which the current symbol is a component. 

L 


ITERAL 


DSTSK_STK_PUSH_OUTER_REC = $g: ! Push Outer Record Address 
DSTSK_STK_PUSH_INNER_REC = 45; ! Push Inner Record Address 


! Define the highest op-code value accepted by the DST Stack Machine. This 
: value is used for op-code range checking. 
LITERAL 

DSTSK_STK_HIGH = 44; ! Upper bound for range checking 


! END OF VALUE SPECIFICATION DESCRIPTION. 


— — — — — — — — — — — — — — —— —— —— ——— ————— — — 
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byte 
byte 
byte 


var 


var 
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THE TYPE SPECIFICATION DST RECORD 


The T ype Specification DST record gives the most general aote type 
descr gt ion available in the Debug Symbol Table. It contains 
name of the data type bein , descr bed ne a DST “Type Soest? tcok tan 
that describes the type. The type name is used in languages where 
data a can be named, such as PASCAL. If no type name exists, 
(the name of zero length) is —28 ed in this record 
DST Type Specifications are described in detail in the next section 
of this definition file. 


Type Specification DST records either immediately follow Separate 

Type gece iT Scat ten DST records or are pointed to by Indirect Type 

ppet Sy ications or Novel Length Type Specifications elsewhere in 
DST for the current module. 


This is the format of the Type Specification DST record: 


— ere ror — — rT ee Se — Ze DZ © — 2 — 2 2 — 2 eo wm cee — — — — — — — ——— + 


H DSTSB_LENGTH ' 


bana we enter emcee w es —— —— Seeeeeoeonoeoeeo See ee om ee em — —— —— —— (oe ee ae ee ce me oy 


: DSTS$B_ TYPE (= DSTSK “TYPSPEC) 


perme ronan ane meme emonceme eneeeeceesson SBeooeaae Sere eae wero wm aa mae $ 


: DSTSB_ TYPSPEC_NAME i 


tower meer soon ese ree soe em ee2eoeoeoeoeeoe 4 


The Type Name in ASCII 
(The name's length is given by DST$B_TYPSPEC_NAME) 


DSTSA_TYPSPEC_TS “ADDR 
The DST Type Specification for the 
Data Type being defined 


0—— 
J — — 


Define the fields of the Type Specification DST record. 


IELD esrerwrerec -FIFLDOS = 


DSB. TYPSPEC NAME C 2. J J. 
DSTSA_TYPSPEC_TS_ADDR -CC 3, A_ ] 
TES; 


" 


' 
} ASCI 
: Specification 


56 


! The count b 4 for the Counted 
am 
! The location 9— the DST Type 
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££ — — — — — — — — — — — — — — — — — — 


— — — —————————a———aa————·c—a————————— 


word 
byte 


var 


DST TYPE SFECIFICATIONS 


A DST Type Specification specifies the data type of some data symbol. 
DST Type Specifications constitute the most general form of data type 
description available in the Debug Symbol Table. They ore found in 

only one kind of DST record, namely the Type Specification DST record. 
However, some Type Specifications contain nested Type Specifications, 
which permits quite complex type descriptions. for 2— the parent 
type for a Subrange data type is given y a nested Type Specification 

within the Subrange Type Specification. 


This is the general format of all DST Type Specifications: 


Pwemoosenacen wee eeeceoe western ener wm BF BB mB 22 ew eer ocamw wmwmrr=@Z® PB we we eee mn wew ee oo 24 


DST$W_TS_LENGTH 


-oemmenaseantoeranzrenena eSeeeoeeoeoee@ ewrererwrerececeoeeocererorecero se Seat etaea cane + 


; DST$A_TS_KIND ; 


momo oce ee cewe emo eros eae eee — —— ee Se ee eee 2— 22—— we memo eee f 


vata symbol whose data type must be described by a DST Type Specifi- 
ation is described by a Separate * Specification DST record. This 
ST record is immediately followed by a Type Specification DST record 
which contains the DST Type Specification for the symbol's data type. 


A 
c 
D 


To conserve DST space when several * have the same data type the 
Type Specification that follows the Separate Type Specification DSf 
record may be an Indirect Type Specification. he Indirect Type Speci- 
fication then contains a DST pointer to the actual Type Specification 
DST record for the symbol's type. oaty . single copy of this actual 
Type Specification is then needed. Multiple symbols of the same Record 
or Enumeration type must also use Separate Type Specification DST 
records followed by Type spec tT icetton OST records containing Indirect 
Type Specifications. n this case, the Indirect Type Specifications 
point to the Record Begin or Enumeration Type Begin DST record for the 
record or enumeration type being specified. 


In fact, the only Type Specification that can refer to a record or enum- 
eration type is the Indirect Type Specification. (The Novel Length Type 
Specification can too but is not noraa( ly used this wey) This Type 
Specification is thus used within other ype Specifications when record 
or enumeration types must be specified. For example, when the element 
type of an array is a record or enumeration type, it is specified by * 
Indirect Type Specification within the Array Type Specification. Simi- 
larly, if the corges of a typed pointer is a record or enyaerat jon type 
obiect, the target type is specified by an Indirect Type Specification 


— — — — — —— — —— — — — — — — — — — ——— —— —— ——— — — — — 
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within the Typed Pointer Type Specification. 


1 
1 
' 
i 
i Define all the fields that can appear in the various Type Specifications. 
Also define the declaration macro. 
F 


IELD DSTSTYPE_SPEC_FIELDS = 


DSTSW_TS_LENGTH =(C0, 0.1], The “tose Length of the Type 
ification nor — 
this hength ft 
pst $B_ Ts KIND = > Oo. ae The Type Speci ication eis 
TS_ATOM_T = » O. we The Atomic data type code 
DST Tea7 TS_ 3 "Ospec LADDR = : a oe The VAX descript or Value Spec 
DST$L_TS_IND = » i. ae endicoct ype Spec DST pointer 
DSTSA_TS_TPTR_TSPEC_ADDR= » — oe Typed Pointer parent type Type 
Specification location 
DST$B_TS_PIC_DLENG ft 3, & 2, byte Length of data sbjects 
of this picture ‘Yer 
DSTSB_TS_PIC_LANG =(€4, 6.1], The DST Language —— or this 
picture data t 
DST$SB_TS_PIC_PLENG 2th & & The Length of the ; Pture 
string in this Type Spec 
DSTSA_TS_PIC_ADDR 26, kh The location where the picture 
is encoded in Type Spec 
DST$B_TS_ARRAY_DIM = f ~m & ae The number of array dimensions 
DSTSA_TS_ARRAY_FLAGS_ADDR=[ 4, A_ J, 


The location of the * flags 
p 


Location of Value Spec c giving 
base address of PL/I area 
The “‘novel"’ Length in bits of 
ob ects of this data type 
DST “os —* = A igh type for 
Length’ type 

Table. ots for this array of 
PL/I Self-Relative Labels 


that ghee Type Specs 
for the empece tet types 
DSTSL_TS_SET_LENG — 3, 4. 3 Length in bits of data 
bjects of this Set type 
DSTSA_TS_SET_PAR_TSPEC_ADDR = [ 7, A_ J,! The Location of = seq s 
parent type Ty pe Spec 
DSTSL_TS_SUBR_LENG e{ 3,4. 3. The Length in bits of objects 
of this subrange type 
DSTSA_TS_SUBR_PAR_TSPEC_ADDR= [ 7, A_ ], becet ion of the parent type 
ree Spe cit cat ten on 
the Su renge Vype e Spec 
DSTSB_TS_FILE_LANG = f a }- Language code for file type 
DSTSA_TS_FILE-RCRD_TYP =[( 4, A_ J, Location of Type Spec giving 
element type for : , 
DSTSA_TS_AREA_BYT = f : AL }: Length in bytes of PL/I ‘‘area’ 
DSTSA_TS_OFFSET YVACSPEC = — a * 
ae 


° 
“” 
1 
FJ 
~ 
un“ 

: 
5 
< 

‘ 
ed 
mm 
z 
a 

" 
gn 
ww 


DST$L_TS_NOV_LENG_PAR_TSPEC = [ 7, L_ J, 
DSTS$L_TS_SELF_LENG ethe.3 
TES; 


— 
a 
oO 


MACRO 


DSTSTYPE_SPEC = BLOCKC BYTE] FIELD(DSTSTYPE_SPEC_FIELDS) 2; 
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} The following are the values that may appear in the DST$B_TS_KIND field. 
LITERAL 


~< 
v 


E_LOWEST 


DSTSK_TS_DTYPE_ = 1, ! =--Lowest ig od Spec kind 

DSTSK_TS_ATOM = 1, ! Atomic Typ pec 

DSTSK_TS_DSC = ¢° ! VAX Standard esciptor Type Spec 

DSTSK_TS_IND = 3, ! Indirect Type Spec 

DSTSK_TS_TPTR = 4, ' Typed Pointer «type Spec 

DSTSK_TS_PTR = 5, ! Pointer T pe * 

DSTSK_TS_PIC = 6, ! Pictured pec 

DSTSK_TS_ARRAY = 7, : te wae Type Spec 

DSTSK_TS_SE1 = 8, ! Set Type 

DSTSK_TS_SUBRANGE = 9 : Subrange —8 5 

3 Unused=-ave® lab e for future use 

DSTSK_TS_FILE = 11, ' File Type Spec 

DSTSK_TS_AREA = \¢- ! Area Ty ype Spec (PL/I) 

DSTSK_TS_OFFSET = 13, ! Offset ype Spec y kay 

DSTSK_TS_NOV_LENG = 14, ! Novel Length ype Spec 

DSTSK_TS_IND_TSPEC oe %,. ] ees internally generated pointer to 
, rele Spec (cannot — in DST) 

DSTSK_TS_SELF_REL_LABEL = 16, ! Self-Relative Label Type Spec (PL/I) 

DSTSK_TS_RFA = 17, ' Record File Address Type Spec (BASIC) 

DSTS$K_TS_TASK = 18, ! Task Type Spec (ADA) 

DSTSK_TS_DTYPE_HIGHEST = 18; ! ===Highest Type Spec kind 


: The following set of Literals give the Longehe in bytes of those Type 
i : Specifications which have a fixed Length. 


LITERAL 
DST$K 43 ~ATOM_LENG 
DSTSK_TS_IND_CENG 


DSTSK_TS_FILE_LENG 
DS “LENG 
DSTSK_ LE ~OF FSET LENG 


DSTS$K_TS_NOV_LERG_LENG 
DS TSK: TS_TASR_LENG 


Atomic Ty ype Spec length 
Indirect Type Spec length 
Shey ol Type Spec length 

ile Type” pec Length 
oe Type Spec length 
Offset. oe Spec length 
Novel Length we Spec Length 
Task Type Spec length 


— es 8 © 8 6 


WNW we 


m — — Æwwhu —— —ñ —ñ— — —— — — _ — —— — — ——— — ——— — 
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ATOMIC TYPE SPECIFICATIONS 


The Atomic Type spec St icet ian is used to describe an atomic VAX standard 
data type. is ype Specification consists of the standard — Speci- 
fication header followed by a gingte byte Cente tates the VAX standard 

data type code (one of the DSCSK_DTYPE_x codes). The Atomic Type Speci- 
fication has the following format: 


+ —— — ù— — SSS SSS SSS 2 SS SSSSSS2S2S222626 “ase nrewrwreerere — ewe wre wren onen = eon} 


word | DST$W_TS_LENGTH (= 2) 

Seeeeeaeaeooaonee ee eee ee te Setvtest en BeBe @ ene we eee see wee ws ew oe om ee ee 
byte DST$B_TS_KIND (= DST$K_TS_ATOM) i 
byte | DST$B_TS_ATOM_TYP i 


DESCRIPTOR TYPE SPECIFICATIONS 


The Descriptor Type Specification is used for VAX Standard Data Types 

that can be described by VAX Standard Descriptors but cannot be de- 

scribed by an atomic type code. Packed decimal, which requires a 

digit length and a scale factor, and ASCII text, which requires a 

ptrieg length, are examples of such data types. The Descriptor Type 

Specification contains a Value Specification which must produce a 

VAX Standard Descriptor. This is the format: 


por eer cre ceeeree Wee ee eee Seem moeoer renee eee e Saas ee er eee wees + 


word ‘ DST$W_TS_LENGTH : 
byte : DSTSB_TS_KIND (= DSTSK_TS_DSC) i 
var i DSTSA_TS_DSC_VSPEC_ADDR 
; Value Specification Yielding a VAX Standard Descriptor 
e Seer eoeeeoeeeoeeeeoeoeo SSeS SS SS SSS SSS SSS SSS — 
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INDIRECT TYPE SPECIFICATIONS 


The Indirect Type Specification is used when the actual Type Specifica- 
tion desired is found in another DST record. This Type Specification 
contains a DST pointer which points to that other DST record. he DST 
pointer contains the byte offset relative to the start of the whole DST 
of the DST record that gives the actual type information. The pointed- 
to DST record must be one of vores kinds of DST records: a Type Speci- 
fication DST record, a Record Begin DST record, or an Enumeration Type 


Begin DST record. fhe Indirect ype Specification is the only Type 


Specification that can refer to a record or enumeration type; those 
trees are too complex Cpotent rath y? to be referred to any other way. 
This is the format of the Indirect Type Specification: 


+ 
; DST$B_TS_KIND (= DST$K_TS_IND) } 


tome ncenr ec nas ee ee eo eeoeeceeececoeeoceces + 


— 


F 
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TYPED POINTER TYPE SPECIFICATIONS 


The Typed Pointer Type Specification describes a typed pointer data 
type, ge a pointer to a specific other data type. Pointer-to- 
integer, as found in PASCAL and other Languages, is an example of a 
type pointer type. In this example, integer is the * type. 
This Type spect ication contains an embedded Type Specification which 
specifies the parent type for the typed pointer type. This is the 
format of the Type Pointer Type Specification: 


doe wenn ne — — — — — ——— — — —— wer 2 2 2— — — 2 nee ee w= swe om eam naam + 


word ; DSTSW_TS_LENGTH 

eh —— ~DSTSB_TS_KIND (= DSTSK_TS-TPTR) ﬅmAACC 
var ATS 
Type Specification. for Parent Type that 


Objects of Typed Pointer Type Point to 


} eeoeccceccccce } 5— 


POINTER TYPE SPECIFICATIONS 


The Pointer Type Specification is used for pointer types which are not 
typed, meaning that the type of object that the pointer points to is 
not known at compile-time. PL/I — are examples of this kind of 
pointer type. Since there is no known parent type, none is specified 
in this Type Specification. The Pointer Type Specification thus has 
the simplest poss ibt format: 


eee wmonr wm now near nme nm sone ws Cee SoM OB eMC EEO aw ewecem one Se ee ewe seem ee + 


‘word ; DSTSW_TS_LENGTH (= 1) t 
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PICTURE TYPE SPECIFICATIONS 


The Picture Typs Specification is used for picture data types as found 
in COBOL and PL/I. Because the exact semantics of picture data types 
vary between languages, this Type Specification contains the Language 
code associated with this —— fic picture type. It also contains the 
byte length of objects of the picture type, an ey ty of the picture, 
and a language-specific picture encoding (usually the EDITPC pattern 
string). The actual data objects of the picture data type are assumed 
to be represented as ASCII character strings. 


This is the format of the Picture Type Specification: 


eb Seo a oe Ce SM IO a Sore soe 

bree aaa eT TAIT 

— — — — —— 

— i— —— —— 

— —— SO ISP ⏑ —— 

var} DSTSA_TS_PIC_ADDR 
Picture String Encoding 
— — ein ; 

tae ; Value Specification Yielding a ! | 
Language-Specific Encoding of Picture Semantics | 
BREASTS — — a | 


The DST$B_TS_PIC_DLENG field contains the Length in bytes of each data 
object of this picture type. DEBUG assumes that picture objects are 
represented internally as ASCII character strings. 


The Language code in the DST$B_TS_PIC_LANG field is the same as that 
used in the Module Begin DST record. 


The DST$B_TS_PIC_PLENG field gives the byte length of the picture 
socoting in the BSTSA_TS_PIC_ADDR field. The picture encoding in the 
DSTSA_TS_PIC_ADDR fieTd Consists of a sequence of words. The high- 
order byte of each word contains an _ unsigned repetition factor and 
the low-order byte contains the ASCII representat on of the repeated 


' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
— 
picture character. Hence the picture S999.99 is represented by this 
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sequence of byte yalues: ''S or 1 9", 2. (The same 
picture con be uritten as 5536, (0g } 


The optional Value yet thee) a * the end of the hs ong pe Speci- 
fication yields oct ocarese. © A tiie: hg ® 36 ang th eer orms 
the encoding assoc ated with th ; picture Type, 6B uses oth pattern 
string with t bate instruction when doing D posits $ into ob * of 
this Ricture. type. f the Value Specification is omitted, DEBUG can 
only deposit character strings into such objects since it does not know 
how to encode numeric values. 
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ARRAY TYPE SPECIFICATIONS 


The Array Type Specification specifies an Array data type. This speci- 
fication can be guite complex because it not only specifies the shape of 
each array of this type. ut also specifies the ky eaten element 
data type and all subscript data types. The element type and the types 
of the subscripts are given y additional Type Specifications nested 
within the Array Type Specification. 


This is the format of the Array Type Specification: 


tn omer oe See aoe ee See Cee nam awe nm eeewmeemr er eoe nee eee ece em esee eececee} 


1 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
| 
word : DSTSW_TS_LENGTH H 
; byte | DSTSB_TS_KIND (= DSTSK_TS_ARRAY) 
4 een en= See ee ee = Se ee me S&P SST er eee Be wee =e ease = ace nreeeewaese + 
: byte H DSTSB_TS_ARRAY_DIM H 
var | DSTSA_TS_ARRAY_FLAGS_ADDR 
; Bit Vector of Flags Indicating What Type 
; Specifications are Given Below 
; (The vector’s bit Length is given by DST$B_TS_ARRAY_DIM) 
— ! 
i ¢eeeececeoca — —2— — — — — — — — —— — — — eee — — ——— — — — — —2— seeeceee + 
! var H ' 
‘ Value Specification Producing an Array Descriptor ‘ 
i ‘ — — — — — — — (SSS ee we we — wo eS — wm — — — — — — SD OD me me oe em ete Soe ee Se eS 2 — — 3 
' var : ' 
‘ Optional Type Specification for Array Element Data Type ‘ 
i 
i toma ee — — — — — —— (Oe — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —— — — — — — — — 
! var : : 
: ‘ Optional Type Specification for First Subscript Data Type 
i : 
i eee — — *2 — — 2 — —2 — — ——— —— — — — 2 2— — were see — ewer ees er eon e reer mec a } 
var ' 
; More Optional Type Specifications for Subscript Data Types 
' gran ase reese none nna eoreaen — — — — — — — — — — — — — à— —————————— eee eran eee + 
1 
i 
i 


Here the DST$B_TS_ARRAY_DIM field gives the number of dimensions of this 
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array 3 Next, DSTSA_TS_ARRAY_FLAGS_ADDR gives the location of a 
prcawes or which indicates ont nested Type Specifications are found 
later in this Array Type Specification. f bit 0 is set, a nested Type 
Specification is included for the oreee element type (the cell type). 
After that, if bit n is set, a nested Type Specif gation for the n-th 
subscript type is included in this Array Type Specification. If a bit 
in the bit-vector is zero (not set), the corresponding Type Specifica- 
tion is omitted from the Array Type Specification. If the element type 
specification is omitted, the element type is assumed to be given by the 
arcey descriptor’s DTYPE field. If a subscript type specification is 
omitted, the 2* type is assumed to be longword integer (DTYPE_L). 
(Subscript Type Specifications are mainly needed for enumeration type 
subscripts as allowed in PASCAL.) 


The number of bits in the bit-vector is DST$B_TS_ARRAY_DIM plus one more 
for the elem-nt type. The whole DSTSA_TS_ARRAY_FLAGS_ADDR field is of 
course rounded up to the nearest byte Boundary. 


The array descriptor Value Specification that follows the bit-vector 
field produces a VAX Standard Descriptor for the 553— (The descriptor 
class must be DSCSK_CLASS_A, DSCSK_CLASS_NCA, or DSCSK_CLASS_UBA.) This 
array descriptor gives the strides (or multipliers) and the Tower and 
upper bounds for all of the array dimensions. It also gives the element 
data type, including its scale factor, digit count, or other type infor- 
mation as 22* e. However, the descriptor’s element type can be 
overridden an element type Specification as noted above; in this case 
the DSCSB_NPTYPE field of the descriptor should be zero. 


The Array Type Specification is normally only used in two situations. 
First, it is used if the array type does not have a compile-time-con- 
stant descriptor (for example, if it has variable array bounds) and no 
run-time descriptor exists in the user's address space. Second, it is 
used if the array type cannot be described a VAX Standard Descriptor, 
either because the element type cannot be described by a VAX Standard 
Descriptor or because the subscript types are not integers. (Element 
types such as records, enumeration types, and typed pointers cannot be 
described hy VAX Standard Descriptors.) If neither of these situations 
pertains, there are simpler ways of describing array types in the DST 
using Standard Data or Descriptor Format DST records. 
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word 
byte 
long 


var 


SET TYPE SPECIFICATIONS 


The Set Type Specification specifies a Set data type as in PASCAL. A 
Set type always has a parent data type. for the set-of-integers type 
for example, integer is the parent type. The parent type must be either 
integer, some enumeration type, or a subrange of those types. DEBUG 
assumes that the Set type is represented internally as a bit-string 
where a given bit is set if and only if the — integer or 
enumeration type element is a member of the set. The n-th bit of the 
bit-string (starting at bit 0) is assumed to cerrocpens to the n-th 
element of the parent type. The length of the bit-string is part of 

the Set type and is specified in the Set Type Specification. 


This is the format of the Set Type Specification: 


weer emow neers mee nce amas wa eeeee cen aE 2 2 2 2 eee nce er wana e oe Seana ae ae + 


‘ DST$W_TS_LENGTH ' 


—— —— — — SSS OFZ BF TOFS SMM Oe eB fee een ean ns 2 — 2 2 2 2—— + 


DSTSB_TS_KIND (= DSTSK_TS_SET) ' 


— cerem nnn ne nee em ee mem mee — — — — — — 


DSTSL_TS_SET_LENG ' 


Se eeeoeeoeooeoeoeoeo Seeeoeoeonoeoeooeoe Seeeeeeeeeooeee Seeeeeoooeoeoenoeoeneaeaea eo ee 


DSTSA_TS_SET_PAR_TSPEC_ADDR 
Type Specification Specifying the Set's Parent Type 


--+ 


4 


Here the DSTSL_TS_SET_LENG field gives the bit length of an object of 
the Set data type. DSTSA_TS_SET_PAR_TSPEC_ADDR marks the Location of 
an embedded DST Type Specification for the parent type of the Set type. 
Typically this is an Atomic Type Specification for type integer, an 
Indirect Type Specification that points to an Enumeration Type Begin 


DST record, or a Subrange Type Specification. 
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SUBRANGE TYPE SPECIFICATIONS 


The Subrange Type Specification describes a Subrange data type, meaning 
a subrange of some ordinal type such as integer or an enumeration Sype, 
This Type Speci Ticat ion specifies the parent type (the original ere 
type? and the lower and peer bounds of the subrange. It also gives the 
bit length of objects of the Subrange type. This is the format of the 
Subrange Type Specification: 


$e Oe OOOO OS CO OOOO SS SS SS SSSSSSSSSSSSSSSSSSSeSeSeossoeseseooseooen + 


word H DSTSW_TS_LENGTH H 
byte : DSTSB_TS_KIND (= DSTSK_TS_SUBRANGE) H 
Long i DSTSL_TS_SUBR_LENG H 
vari DSTSA_TS_SUBR_PAR_TSPEC_ADDR 
Type Specification Specifying the Subrange's Parent Type 
—— — — — — — — — 
var : ' 
i Value Specification Giving the Lower Bound of the Subrange 
— ———— —— — — — + 
var H t 
' Value Specification Giving the Upper Bound of the Subrange ' 
— — — — — —— — — + 
Here the DSTSL_TS_SUBR_LENG field e length in bits of objects 


ives th 
of the Subrange data type. DSTSA 9s SuBR PAR_TSPEC_ADDR marks the 
location of a DST Type pecification for the parent type of the sub- 
range. Typical ty this is an Atomic Type Specification for type integer 
or indirect Type Specification pointing to an Enumeration Type Begin 
record. 


The two Value Specifications in this Type Specification specify the 
lower and upeer bounds of the subrange. These bounds values must be 
e parent type. 


values of t 
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i word 
i byte 
i byte 
i var 


FILE TYPE SPECIFICATIONS 


The File BS oh Specification specifies a File data t type as Hite in 
/I, \e fee 


le 
the Type Specification. Optionally, a fit record 
type seps*s scot ten can be included Spec tt ying the type of a record 
t f or instance, would have Real 


PASCAL or for * le. Since the interpretation of f 
varies ‘con Language to anguage, the language code for this 
type is include 


le type. A PASCAL File-of-Reals, 
(F=F Loat ing as its file record type. 


This is the format of the File Type Specification: 


¢ ere romeo meee mee eee Bee eee meee we wen ee meee ecm ecm ee oe ee meee mmm mm ee} 


DSTS$W_TS_LENGTH 


temo rome meme eee em ee ee eee ee ewe eee we meee eee meme meee emcee ee ee mem mw en 


H DSTSB_TS_KIND (= DSTSK_TS_FILE) 


boar macnece eeeee SB eT eB eS Se SS eB ee Heme = emer ranean om ew me mee aa $+ 


H DSTSB_TS_FILE_LANG 


¢ were nwceweeeeon eee = seecee SSS SSS SSS SSS SSS eonenenenene — e + 


DSTSA_TS_FILE_RCRD_TYP 
Type Specification Giving the File Record Type 


@} cccsccccce 


mre the DST$B_TS_FILE_LANG field contains fhe Language code for Fete 


le. The same —— age ¢ codes are used as in the Module Begin D 
record. DSTSA_TS_F ue 
cation for the record type F mottos This Type Spec 


optional; if omitted, oe ae teense is assumed. 


ercRD_t P is the pecat ioe of a DST Type Seec tt i= 
cation 
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AREA TYPE SPECIFICATIONS 


NOTE: THIS TYPE SPECIFICATION IS NOT SUPPORTED BY DEBUG V4.0. 


The Area Type Specification describes a PL/I ‘‘area'’ type. PL/I areas 
are regions of memory whose base addresses are determined at run-time. 
Areas are always used in conjunction with PL/I Offsets (see below). 


This is the format of the Area Type Specification: 


eee ee ores 


word | DST$W_TS_LENGTH i 
byte | DSTSB_TS_KIND (= DST$K_TS_AREA) i 
var DSTSA_TS_AREA_BYTE_LEN ; 


Value Specification Giving the Area Byte Length 


2 


' 
' 
‘ 
‘ 
' 
' 
' 
' 
+ 


Here the DSTSA_TS_AREA_BYTE_LEN Value Specification specifies the byte 


Length of the PL/T Area. 
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OFFSET TYPE SPECIFICATIONS 


NOTE: THIS TYPE SPECIFICATION IS NOT SUPPORTED BY DEBUG V4.0. 


The Offset Type Specification describes a PL/I ‘offset’ type. PL/I 
offsets are offsets relative to the start of a PL/I ‘‘area’’ (see above), 
a dynamically allocated region of memory. The Offset Type Specifica- 
tion specifies the base address of the associated area and the byte 
offset value of this offset type. This is the format: 


deweese ree nme rc ecenm earner nea e — — —— SSeS SSS SSS 2 2 — — + 


Value Specification Giving the Byte Offset Value 


word H DSTSW_TS_LENGTH H 
byte ‘ DSTSB_TS_KIND (= DSTSK_TS_OFFSET) H 
var} DSTSA_TS_OFFSET_VALSPEC 
Value Specification Giving the Base Address 
of the Area Associated with this Offset 
ER See eeeaoeoeonoeeoe see ee eee — eH OE Bee Se meee treet een — we wm we Be ee ; 
var i 
+ 


——44 


Here the DSTSA_TS_OFFSET_VALSPEC Value Specification produces the base 
address of the asSociated area and the second Value Specification gives 
the byte offset value into the area. 


ee Re et ed ee — — — — — — — — — — — — — — — — —— 


— — —— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —— —— —— — —— 


' 
. 
' 
. 
' 
. 
' 
. 
— 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
1 
. 
' 
' 
. 
' 
. 
! 
. 
' 
. 
' 
. 
' 
' 
. 
' 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
. 
' 
: 
! 
' 
. 
' 
. 
! 
. 
i] 
. 
' 
. 
' 
* 


word 
byte 
Long 
long 
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NOVEL LENGTH TYPE SPECIFICATIONS 


The Novel Length Type Specification is used to spec tty — data we 
that is identical to a parent data type except t e objects of this 
new type have a different length (a ‘‘novel"’ or atyeices length). This 
rype pecification is used for the components of PACKED records in 
PASCAL, for example. A boolean component of a packed record consists 
of a single bit (the novel length) while all other booleans consist of 
a byte (the normal length). To describe the packed boolean type, a 
Novel Lenath Type Specification is used which specifies the novel Length 
and points to the DST description of the parent type, namely the normal 
boolean type. DEBUG accessed objects of a Novel=-Length type by expand- 
ing them to the normal length for that type. 


This is the format of the Novel Length Type Specification: 


$eeee eee eee sre eee ee eee Smee emer arma e ane Sewer ence eoc en aenre ann nman awe e — 


DST$W_TS_LENGTH (= 9) 
‘eases ~ DSTSB_TS_KIND (= DSTSK-TS.NOV_LENG) 575 H 
“oes Se ; SN Ee Ee i 
Fe aeeenen ease DSTSLITS.NOV.LENGPARLTSPEC 


Here the DSTSL_TS_NOV_LENG field contains the ‘novel’ length of this | 
data type. The DSTSL_TS_NOV_LENG_PAR_TSPEC field is a DST pointer which 
contains the byte offSet relative to the start of the whole DST of the 
DST record that specifies the parent type. The pointed-to DST record 
must be a Type Specification DST record, a Record Begin DST record, or 
an Enumeration Type Begin DST record, a ypteee ty it is a Type Specifi- 
cation DST record containing an Atomic Type sere fication for type inte- 
ger or boolean or an Enumeration Type Begin DST record.) 


1 
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word 
byte 


word 
byte 


SEL” “RELATIVE LABEL TYPE SPECIFICATIONS 


The Self-Relative Label Type Specification specifies the type of a —* 

self-relative’’ label. Such a label is actually a label array. meaning 
that it must be indexed by an integer value to yield a specific label 
value, The internal representation consists of an array of longwords 
where each rer element contains a label value relative to the start of 
the array. Mak ng the element values relative to the start of the array 
ensures that the label array is Position-Independent (PIC). 


This is the format of the Self-Relative Label Type Specification: 


+ = ee 
DST$B_TS_KIND (= DSTSK_TS_SELF_REL_LABEL) ; 


toe ne eee weeeee nn ee een wenren = See cee en nm acca e wee wrasrermrsaoan emma naacaaoe os + 


TASK TYPE SPECIFICATIONS 


NOTE: THIS TYPE SPECIFICATION IS NOT SUPPORTED BY DEBUG V4.0. 


The Task Type Specification specifies the data type of task objects 
as found in ADA. Objects of the Task data type are assumed to have 
longword values understood by the ADA multi-tasking kernel. Since 
no additional information is associated with the Task data type, the 
Task Type Specification has the minimal format: 


¢enmeenm emer come ose sere ween ree mw eoec moe meter o ene enone wees ere een were ee + 


“DSTS$W_TS_LENGTH (= 1) 


¢eececeeneoaces Sow eee eer ee eo eH ee wert ee ewe Be BE BE Oe SBM Te OF eB Oe eB eS + 


DST$B_TS_KIND (= DSTSK_TS_TASK) 
+ 


END OF TYPE SPECIFICATION DESCRIPTION. 


= — — — — — 
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ENUMERATION TYPE DST RECORDS 


Enumeration types. as found in PASCAL and C, are represented in the 
DST by three kinds of DST records. The Enumeration 7* Begin DST 
record describes the type itself, giving the bit length of objects 

of that type and the name of the type (e.g., COLOR). This record 

is followed by some number of Enumeration Type Element DST records, 
one for each element, or Literal, in the type (e.g., RED, BLUE, and 
GREEN). Each Enumeration ‘ye Element DST record gives the name and 
numeric value of one Literal of the enumeration type. The whole type 
description is then terminated by an Enumeration Type End DST record. 


The Enumeration Type Begin and Enumeration Type End DST records thus 
bracket the List of elements of the type, much Like other Begin-End 
pairs in the DST. The Enumeration Type Element DST records within 
those brackets do not have to be in numeric order of their values, 
although it is desirable if they are. For languages Like ADA, where 
the numeric values of the elements need not go up sequentially with 
the logical element positions, the Enumeration Type DST Elements do 
have to be order of their logical positions, however. No other kinds 
of DST records (except Continuation DST records) may appear between 
the Enumeration Type Begin and the Enumeration Type End DST records. 


F 
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THE ENUMERATION TYPE BEGIN DST RECORD 


The Enumeration Type Begin DST record specifies the name of an 
enumeration type and the bit Length of Objects of that type. 

It also serves as the — bracket for a List of Enumeration 
Type Element DST records, and must_be matched by a closing 
Enumeration Type End DST record. This is record's format: 


+ eseeeoe ae reer enereoecee = See — ——— — —— ù22— ———— * 


1 
i 
i 
i 
i 
i 
i 
i 
i 
} byte : DSTSB_LENGTH H 
byte | DSTSB_TYPE (= DSTSK_ENUMBEG) ' 
i byte : DST$B_ENUMBEG_LENG : 
i byte : DST$B_ENUMBEG_NAME : 
i var H ' 
The Name of the Enumeration Type in ASCII ‘ 
; (The name's Length is given by DSTSB_ENUMBEG_NAME) 
eee ! 
i Pree ee ee few ewe eee em eo eo men wee ee eee os + 
1 
Define the fields of the Enumeration Type Begin DST record. 
FIELD DSTSENUMBEG_F IELDS = 
DSTS$B_ENUMBEG_LENG =C€2,6.], ! Bit length of data objects of 
: this enumeration type 
DSTS$B_ENUMBEG_NAME ‘> &.2 


!' Count byte for the Counted 
we : ASCII Type Name 
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THE ENUMERATION TYPE ELEMENT DST RECORD 


The Enumeration Type hee DST record specifies the name and value 
of one element (one Literal) of an gemperes ton 7: It may only 

ap ear between an Enumeration Type Begin and an nuneration. Type. End 

DST record. The underlying represents ten of enumeration types is 
assumed to be unsigned integer. DSTSB_VFLAGS field in t is record 
has its normal interpretation lor” A. Standerg Data DST record for 
the details). Hence the DSTSV_VALKIND field will have the value 
DSTSK eyALKING LITERAL and the BSTSL_VALUE field will have the appro- 
priaté integer value in this case. 


This is the format of the Enumeration Type Element DST record: 


H Ds Ts8_ NAME 


+ 
q 
5 
q 
4 
— 
6 
4 
a 
8 
0 
4 
a 
t 
1 
t 
t 
— 
a 
t 
a 
t 
' 
4 
; 
' 
4 
i) 
8 
‘ 
5 
8 
6 
8 
a 
t 
‘ 
3 
a 
1 
rT 
4 
‘ 
‘ 
‘ 
4 
t 
A 
a 
Q 
4 
a 
‘ 
a 
‘ 
a 
a 
. 
8 


The Name of the Enumeration Literal in ASCII 
(The name's Length is given by DSTSB_NAME) 


Pee — — 


THE ENUMERATION TYPE END DST RECORD 


The Enumeration Type End DST record terminates the description of an 
enumeration type. This is the record's format: 


: DSTSB_LENGTH ' 


Power wo em ene mason nae fee eee nr ee mre em emo wm mone terme er ree eee ance eee = + 


' DSTSB_ TYPE (= DSTSK -ENUMEND) \ 


Poe sr Hm mH OE OEE HR RE RRO ORO BDO ODEO OEE HO ODE Dee * 


H 
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RECORD STRUCTURE DST RECORDS 


Record structures, or simply records, refer to the aggregates of non- 
homogeneous components found in many banguages In some Languages, 
such constructs are called ‘records’ (in PASCAL and COBOL, for example) 
and in others they are called ‘structures’ (in 1, for example). 
Here we will call them “records’’. What all records have in common is 
that they consist of a set of named components, each corresponding to 
some field in the record structure. The components can in general be 
of any data types supported by the Language. 


In the oo ns Table, a record is represented by a Record Begin 
DST record followed by some number of data object DST records, one for 
9* record component, followed by a Record End DST record. Any data 
object DST record within a Record=-Begin/Record-End pair is taken to 
denote a component of that enclosing record specification. Other DST 
records may also appear between the Record-Begin/Record-End pair, such 
as Type Specification and other DST records that specify the data types 
of t 4 components. However, only data DST records denote record com- 
ponents. 


Nested records are defined by record components which are themselves 
records. The type of a record component which is itself a record is 
defined by another Record-Begin/Record-End pair of DST records. This 
additional record definition may appear inside the original record 
definition, but does not have to do so--an Indirect Type Specification 
pointing to a record definition outside the original record definition 
is also legal. Conversely, a record definition inside another record 
definition does not define a nested record unless some component of 
the outer record actually references the inner record definition. In 
short, the DST can only describe one level of record components at a 
time, but any component can be of any arbitrary data type including 
another record type. 


The Record Begin DST record is unusual in that it can define both a 
data tyes and a data 2** If the DST$B_VFLAGS field has the special 
value DSTSK_VFLAGS_NOVAL, then the Record Begin DST record defines an 
abstract data type. — object of this data type must be represented 
by a Separate Type Specification DST record which — ee | precedes 
either the Record Begin DST record or a Type Specification DST record 
that contains an Indirect Type Specification that points to the Record 
Begin DST record. In this case, the name in the Record Begin record is 
taken to be the name of the data type, not of any object of that type. 


However, if the DSTSB_VFLAGS field does not contain DSTSK_VFLAGS_NOVAL, 
then the Record Begin DST record defines both a data type and a data 
object of that type. This form can be used for languages such as COBOL 
which do not have named data types. In this case, the DSTSB_VFLAGS and 
DSTSL_VALUE fields specify the address of the record object jn the same 
way as in the Standard Data DST record. It is still legal to have 
Indirect Type Specifications pointing to this Record Begin DST record, 
using it strictly as a type definition. 


Some languages, such as PASCAL, allow record variants. (Im ADA, the 


— — 7y 
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same concept is called ‘‘discriminated’’ records.) An object of a record 
type with variants contains some set of components found in all objects 
of that type plus some set of conpenents that vary from one record 
variant to the next. Which of the varying components are actually 
present in a given record may be determined by the value of a ‘'ta 
variable’’ which is a fixed component of the record. Variants may also 
be nested so that variants have variants. 


In the DST, record variants are described by Variant Set Begin DST 
records, Variant Value DST records, and Variant Set End DST records. 
The Variant Set Begin DST record marks the beginning of a set of record 
variants, where each variant consists of some set of record components. 
The Variant Set Begin DST record indicates which record component con- 
stitutes the tag variable that discriminates between the variants in 
the set. This ag variable must be a component of the same record and 
must precede the Variant Begin DST record in the DST. The Variant 

ot be at Bt also gives the bit size of the variant, if known at 
compile-time. 


The Variant Value DST record marks the — of a single record 
variant. It also specifies all tag variable values or value ranges 
that indicate the presence of this variant in a given record object. 
ALL record components (indicated by data DST records) after this Vari- 
ant Value DST record and before the next Variant Value or Variant Set 
End DST record are taken to be components in this variant. 


The Variant Set End DST record marks the end of some set of variants 
hed © recere specification. It also terminates the last variant 
w n the set. 


A record type with variants is thus specified as follows. First a 
Record Begin DST record marks the beginning of the record specifica- 
tion. After that come data DST records that denote all fixed compo- 
nents of the record type. Then comes a Variant Set Begin DST record 
that marks the beginn 7 of a set of variant definitions and identi- 
fies the tag variable (if any) for that variant set. Immediatel 
thereafter comes the first Variant Value DST record. It marks the 
start of the first variant and identifies the values or value ranges 
of the tag variable that correspond to this specific variant. 


After the first Variant Value DST record come the data DST records 

for the record components in this particular variant. Next comes the 
Variant Value DST record for the next variant, along with its component 
DST records, and so on for each variant in the variant set. After the 
last component DST record for the last variant in the set comes a 
Variant Set End DST record. It is followed by the DST records for any 
additional record components, poss tty including additional variant 

set definitions. Then comes the the Record End DST record. 


Variant sets ney be nested inside variant sets. Such nesting is indi- 
cated in the DS the corresponding proper nesting of Variant Set 
Begin and Variant Set End DST records. 


ü—— — — — — — — — — — — — — —— — ————c————— — — — — — — — — —— — — — — — — — — — — — — 
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THE RECORD BEGIN DST RECORD 


The Record Begin DST record marks the beginning of a record type 
definition in the DST. It must be followed by the DST records for 

the components of that record and by a matching Record End DST record. 
The Record Begin DST record has essentially the same format as the 
Standard Data DST record, but with two exceptions. First, an extra 
Longword gives the bit Length of the record type ene second, the 
DBGSB_VFLAGS field may have the special value DSTSK_VFLAGS_NOVAL to 
indicate that this is strictly a type definition, not also the defini- 
tion of a record object. If a normal value specification is used, a 
record object is being declared as well as a record type. In this 
case, a Trailing Value Specification may be included at the end of the 
DST record if necessary to describe the record's address. 


The bit size of objects of this record type is 24 given in the DST 
record. This size should be included if the size is known at compile- 
time. If it is not known at compile-time, it should be specified as 
zero. 


This is the format of the Record Begin DST record: 


tora nrm ew meme eeeere ten enw ewe rece once oe meee ce — Oe Se wera se a} 


! 
i 
; 
; 
i 
' 
; 
i byte } DST$B_LENGTH 
i 
i 
F 


$¢ ewer een Teme moore roe oe Se eo ewe ewe ee ES Ts Kee SR eee ese ee 222222 + 

byte ' DSTSB_TYPE (=DSTSK_REGBEG) H 

ewe EN eRe BO ee Re oN ee eS SE ee eee em ee ee ee 2— (tA em em ee ee me > ee em 

byte : DSTSB_VFLAGS H 

Long ‘ DSTSL_VALUE H 

byte : DSTSB_NAME i 

var : H 

‘ The Name of the Record or Record Type in ASCII ' 

(The name's length is given by DSTS$B_NAME) 

AE ee ee ee wee — — — — — — — — — — — — — — — — — — aes BS Be ewe mee ee ewe ee . 

long ; DSTSL_RECBEG_SIZE : 

yee — — — — — — — — — sane eee eee eee ewe Se ee ee ee ee ee we ee 

Define the fields of the Record Begin DST record. Also declare the macro 
that defines the trailer part of the DST record. 

IELD DSTSRECBEG_TRAILER_FIELDS = 


DSTSL_RECBEG_SIZE = (0,tL_] : The bit size of data gbjects of this 
TES; 


record type (or f unknown) 
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ee ees eseeecee SeeeeeeeeOeeeGeeenenenenneenan ad 


byte | DST$B_TYPE (= DSTSK_RECEND) 


eee w eee —— —— ——— ù— — — 2— — — — ec eererenereew ec ere = Seen eto en eam ee we aw mea + 


MACRO 

DSTSRECBEG_TRLR = BLOCKC BYTE] FIELD(DSTSRECBEG_TRAILER_FIELDS) 2%; 
: THE RECORD END DST RECORD 
i 
i The Record End DST rogers marks the end of a record type definition in 
, the DsT. = effect, it terminates the scope set up by the matching 
: Record Begin DST record. This is the record's format: 
i 
i teeree 4 
byte ; DSTSB_LENGTH (= 1) : 
i 
i 
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byte 
byte 
byte 
long 
byte 


var 


Long 


! 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
‘ 
i 
i 
i 
i 
long 
i 

i 

i 

i 

i 

i 

f 


MACRO 


THE VARIANT SET BEGIN DST RECORD 


The Variant Set Begin DST record marks the beginning of the DST 
description of a set of record variants. This DST record also 
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identifies the tag variable that discriminates between the variants 


in the variant set. The tag variable is identified by a pointer 
to the DST record for the tag variable. This DST pointer gens jets 
of a arte geerece relative to the start of the DST. The size in 
oits of this variant set, meaning the size of the largest variant 


n the set, is also included. If this size is not known at compile- 


time, it should be set to zero. 
This is the format of the Variant Set Begin DST record: 


ù— — —224 


DST$B_LENGTH 


domo ever ee atom eon emma cen Senco m mow me mom eee arene seme ene eam} 


; DSTSB_TYPE (= DSTSK_VARBEG) 


wees ow mon more renee new eo ener awreocerecaccmeccan seeeeece Seeeeoeoeoneeneo oem ae} 


H DSTSB_VFLAGS ' 


erences sSeeeee SSS SSS SSSSSSSSSSSSSSSSSSS2SESE 2222202 Seeeeeeoeoeoenoanononen + 


DSTSB_NAME ' 


eeeoeoeoe Sweetener De eee Bee eee OS Se Se Re EE ee HEB BESO ESTES ees ee ee} 


The Name of the Variant Set in ASCII 
(The name's Length is given by DSTSB_NAME) 
(This name is normally null) 

+ 


DSTS$L_VARBEG_SIZE 


—— — — —— SSS — — — — — — 2 — — — — — — — — — — — — —— — — ——2— oe te ee ae a 222 


DSTSL_VARBEG_TAG_PTR 


peewee eno cess uan none coer mecca e eee eeeeeooeee eee eee eee eee ———— — — — 


— 


Define the fields of the Variant Set Begin DST record. Also define the 
declaration macro for the trailer part of the record. 


IELD OSTSVARBEG_TRAILER_FIELDS = 


DSTSL_VARBEG_SIZE =C€0,t. 1], ! Size in bits of variant part 
' of record (or zero) 
DSTSL_VARBEG_TAG_PTR =(€4,t.]) ! Pointer to TAG field DST 
! record relative to the 
1es : start of the DST 


— — 
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DSTSVARBEG_TRAILER = BLOCKC,BYTE) FIELD(DSTSVARBEG_TRAILER_FIELDS) 2%; 


m — — —ñe —ñ a —— — — — — — — — —— — — — 
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THE VARIANT VALUE DST RECORD 


The Variant Value DST record marks the beginning of a new record 
variant within a variant set. It also marks the end of the previous 
variant (if _ It is always Youn? between a Variant Set E 

and a Variant Set End DST record. Since the Variant Set Be 

record has already specified the tag variable, the Variant Value 

DST record only specifies the tag value or va un that correspond 

to the present variant. It also specifies the s ze in b ts of this 
variant if known at compile-time (otherwise zero is specified) e@ 
Variant Value DST recere is followed by the Sete DST records (includ- 
ina nested variants if appropriate) which constitute the components 
of this specific variant. 


A variant may have many tag values or tag value ranges. This DST 
record thus specifies a set of tag value ranges. The way these 
ranges are specified is described in detail on the following page. 
This is the format of the Variant Value DST record: 


¢esee es eeecoeeeoe ete wee er Bem Pew eB eB eee rere aewr wren ewe ne nna eae coarse waa > + 


' 
i 
: 
: 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
: 
: 
i 
i 
i 
: byte : DSTSB_LENGTH ' 
i 
i 
— 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
F 


byte an neneennnne DSTSB TYPE (2 DSTEKVARVAL) OT} 
mee ee — — ili alias hia 
ee EL 
var i DSTSA_VARVAL_RNGSPEC ' 
Zero or More Tag Value Range Specifications 
; (The number of Range Specs is given by DST$W_VARVAL_COUNT) 
— — ——— — 
Define the fields of the Variant Value DST record. 
IELD DSTEVARVAL FIELDS = 
berbucvanvatceouwt = V—— 
* * — which follow 
DSTSA_VARVAL_RNGSPEC =(€8, A) } Location where the tag value 


range specs star 


TES; 
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TAG VALUE RANGE SPECIFICATIONS 


Each Tag Value Range Specification in a Variant Value DST record 
consists of a byte —— the kind of the range specification 
followed by one or two Value Specifications. If one Value Speci- 

fication is given, that gives the tag value=-the range consists of 
that. one value. if two Value Specifications are given, the 1 4 
fy the lowest and highest values in the tag value range. The illu- 
strations below show the two possible formats of Tag Value Range 
Specifications: 


. oeeece See ZTFZZTZZ£© ®e em teeeonmrmtere ner eceaoetwewaac © oeamrereceemnrwznereerece e2aceae= @ + 


byte | DST$B_VARVAL_RNGKIND (= DSTSK_VARVAL_SINGLE) 


See eeee eee eoeooeeeaene See 22 e2e ee e2eeeeneenene Seeeeoeoeaooeeneo — — —— 


DSTSA_VARVAL_RNGADDR 


var ' 
A DST Value Specification Giving a Variant Tag Value ; 


— ———— ù—— eer eer 2 22 cere ne cw ew 2 — —2— ee ee —— — 


DSTSB_VARVAL_RNGKIND (= DSTSK_VARVAL_RANGE) 
DSTSA_VARVAL_RNGADDR 
A DST Value Specification Giving the Lower Bound 


byte 


var 


for a Range of Variant Tag Values 


var 
A DST Value Specification Giving the Upper Bound 


for a Range of Variant Tag Values 


— 


Define the fields of the Tag Value Range Specification. 
IELD DST PPARUM, NG _FTELOS = 
DST$B_VARVAL_RNGKIND = f 9. 8. 4 ! Tag Value Range Spec kind 


DSTSA_VALVAL _RNGADDR ' Location of first Value 
TES : Specification 


' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
— 
' 
i 
' 
i 
£ 


rin tant 
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: Define the possible values of the DSTSB_VARVAL_RNGKIND field. 


TSK_VARVAL. SINGLE = 1, 
= 


The range consists of a single value 
$K—VARVAL ~RANGE 


! 
2; i The range is given by a lower and an 
: upper bound (two value specs). 


ſ—⸗— 7 ⸗ —ñ — e — — — 
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THE VARIANT SET END DST RECORD 


The Variant Set End DST record marks the end of record variant set; 
it terminates a set of variants which have the same tag variable. 
This is the format of the Variant Set End DST record: 


Fee eceeee eee ee eee ee eeeeeeeeeeeeeeeeeeeeeeeeeesecoassesocacesooeees + 


' DSTSB_LENGTH (= 1) H 


* SSS SS BS OSS SSS SSS SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS“SOESES — 


DST$SB_TYPE (= DSTSK_VAREND) ; 


teen eer weer eww creme men nw een nee ee — — ———— — — — — —— + 


al 
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BLISS DATA DST RECORDS 


BLISS data objects are represented by several different kinds of DST 
records. Ordinary scalar objects, such as simple integers, are repre- 
sented by the Standard Data OST record or its variants. However, the 
more specialized BLISS data types such as Vectors, Bitvectors Blocks, 
and Blockvectors, are represented by @ special DSf record called the 
BLISS Special Cases DST record. Pointers to such objects (e.g., REF 
VECTOR) are also represented by this DST record. In addition, BLISS 
field names are represented by their own kind of DST record, the BLISS 
—* DST record. Both of these record kinds are described in this 
section. 


The BLISS Special Cases DST record and the BLISS Field DST record are 
supported for BLISS only. They should not be generated by compilers 
for any other Language. 


F 4 
DSTRECRDS.REQ;1 16-SEP-1984 16:49:15.30 Page 88 


THE BLISS SPECIAL CASES DST RECORD 


The BLISS Special Cases DST record is used to describe a number of 
fore objects whose data types are specific to the BLISS Language only. 
is includes such objects as BLISS Vectors, Bitvec sort. arr’s and 

— — and pointers to these objects (REF VECTOR groeK® 
and so on). This DST record should not be anol. «3: te —* Language 
other than BLISS. 


This DST records consists four parts: The DST header fields, the 
fields in the set set BSI otha 3a variable-length set of fields, and 
St 


the fields in —— set D 

can f the fields in DSTSBLI_VEC_FIELDS 
the fields in tt i Yer TveEC lets, the fields in + "sect 88 “Fievos, 
or the fields in DSTSELI_BLKVEC_FIELDS. Which set of fields oppear 
in the variable-length part depends on the value of Busy _BL1 RUC, 
which indicates which type of symbol is being defined. 


This is thus the format of the BLISS Special Cases DST record: 


slic Oa — EE —— ——— 
J cenishasbaleientan PID daa Sant — — ———— 
ate aE — vo en EL WEE REA —— 
— — —— —— — EE 
— TORRE ean hme — 
— — note EE BIE aI — 
var DSTSA_BLI_SYM_ATTR ' 

Variable-Length Portion of DST Record 

———— — —— —— 
pe Hh) RR a a EE nn — 
aie | EES EN PS ain a cn EE ONE : 
as The BLISS Symbol Name in ASCII ! 

(The name's Length is given by DST$B_BLI_NAME) 

SEER — — 
—— 
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Long 
byte 


long 


long 
byte 


long 
long 
byte 


The variable-length portion of fhe DST record can have several forms 
as discussed above. One possib ity is that it is absent altogether. 
This occurs if the DSTSV_BLI_STRUC field contains DSTSK_BLI_NOSTRUC. 


However, if DSTSV_BLI_STRUC has the value DSTSK_BLI_VEC, the variable- 
Length portion of the DST record has the following format: 


Sem ee eee ee ee eee eee ee SSSeS SeSSSSSeeSeSSeeeeeeeeeoesseoeooaooesaen + 


H DSTSL_BL1 VEC_UNITS ' 


$e women emer or ee seme men nen nn newane SR re PT ee Sw Ew we Sew SE oe SS Do be 


' DSTSV_BLI_VEC_SIGN_EXT ' DSTSV_BLI_VEC_UNIT_SIZE H 


Gee ece —— —— —— — ee eseeceoe enc ewe 22 — — —226 


If DSTSV_BLI_STRUC has the value DSTSK_BLI_BITVEC, the variable-length 
portion of the DST record has the following format: 


bemeenscenasreoen ener ene — —— —— SSS SS — — — 2 2 — 2 — — — — 2 2 2 — — — — ——— — — 2—— > 


H DSTSL_BLI_BITVEC_SIZE t 


If DSTSV_BLI_STRUC has the value DST$SK_BLI_BLOCK, the variable-length 
portion of the DST record has the following format: 


gwen em ert eres os oe ee Reno naewreawe eer eae wememere nen ene eer were ene meee = + 
‘ DST$L_BL1_BLOCK_UNITS i 
‘ Unused ! DST$V_BLI_BLOCK_UNIT_SIZE ! 


If DST$V_BLI_STRUC has the value DSTSK_BLI_BLKVEC, the variable-length 
portion of the DST record has the following format: 


— eoeoeeoeroeeooeoeces ewer eer eee ese wwe Swern erase waren ene ann ene ee + 
; DSTSL_BLI_BLKVEC_BLOCKS ! 
{ DSTSL_BLI_BLKVEC_UNITS ! 
; DSTS$B_BLI_BLKVEC_UNIT_SIZE 


formes the fields in the header portion of the BLISS Special Cases DST 
ecor 


m — — — — —— — — SE — —— — — — >> Orr ene 


| 
H 4 
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FIELD OSTSAL1 FIELDS = 


DST$B_BLI_LNG =(€2, 6.1], Length in bytes of the set of 
fields between this one 
and_TRAIL_FIELDS 

between 3 and T2 

DSTSA_BLI_TRLR1 =(€3,A,], The first trailer is at this 
location + DST$B_BLI_LNG 

DST$B_BL1_FORMAL ef{ 5, @, 2. Flag set if this symbol is a 
routine formal parameter 

DST$B_BLI_VFLAGS = ‘ 4,8 Value access information 

DSTSB_BLI-SYM_TYPE = 8 The type of the BLISS symbol 


as described by the fol- 
lowing sub-fields: 


— — ——— — ee — 


ce -BLI_STRUC ={ 5. v_(0,3) ! The structure of this symbol 
Se = 5, v_(3,4) ! This field Must Be Zero 
bst$v _BLI_REF =C€ 5, vi(7,1) ! Flag set if this is a REF 
1 = REF, 0 = no REF) 
DSTSA_BLI_SYM_ATTR =(€C6,A, J] Address of variable len — 
attribute segment 
Tes this DST record 


These are the possible values of the DSTS$B_BLI_STRUC fieid. 
LITERAL 


DSTSK_BLI_NOSTRUC = 0, ! Not a BLISS structure 
DSTSK_BLI_VEC = 1, ' BLISS Vector 
DSTSK_BLI_BITVEC = ¢- ' BLISS Bitvector 
DSTSK_BLI_BLOCK 3. ' BLISS Block 
DST$K_BLI_BLKVEC = 4; ! BLISS Blockvector 


! Define the fields in the variable-length Buy struc of BLISS peec tak Cases 
i DST record when the value of the BLI$ -BLI_STRUC Nel d is DSTSK_BLI_VEC. 
This field Soeceibes a BLISS Vector. 
FIELD OSTSOLI_VEC_FIELDS = 
DSTSL_BLI_VEC_UNITS =(€6,t. 1]. ! Number of elements allocated 
: n the vector 
DSTSV_BLI_VEC_UNIT_SIZE = (C 10, v_(0,4) Je ! The vector phonons unit 


size: 1 = byt 
ord, and re : *(ongword 
DSTSV_BLI_VEC_SIGN_EXT = ( 10, v_(4, 0} ! Sign’ extension flag: 
1 = sign extens on 
0 = no sign extension 


TES; 
! Define the fields in the ver tapleston th ort ° BLISS Special 
! DST record when the value of the BLISV_BLI_ ota neg is DSTSK_BL 13 TVEC. 
: This field describes a BLISS Bitvector. 
FIELD DSTSBLI_BITVEC_FIELDS = 
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SEI 
DaTSL BOLI _BITVEC SIZE = (6, L. J] ! The number of bits in the bitvector 


Define the fields in the variable-length part of t 
DST record when the value of the - -BLI_STRUC f 
Trese fields describe a BLISS Block. 


1ELD DSTSAL1_BLOCK FIELDS = 


DSTS$L_BLI_BLOCK_UNITS =(€6, tL. J], ! The number of units allocated 
i in the block 


DSTSV_BLI_BLOCK_UNIT_SIZE = C 10, v_(0, 4) ] ! The unit size of the 
lock: 1 = byte, 
word, and 4 = Longword 


he 
i 


BLISS Special Cases 
eld 


s DSTSK_BLI_BLOCK. 


' 
i 
i 
i 
f 


TES; 


Define the fields in the variable-len i art of the BLISS Special Cases 
DST record when the value of the BLI$ _STRUC fi eld d is DSTSK_BLI_BLKVEC. 
These fields describe a BLISS ochesciene” 


FIELD osToeLt BLKVEC_FIELDS = 
DSTSL_BLI_BLKVEC_BLOCKS ={€6,t.], The number of blocks in the 


ockvector 
DSTSL_BLI_BLKVEC_UNITS 


= Zz 19. -} i The number of units per block 
DST$B_BL1_BLKVEC_UNIT_SIZE = he block unit size: 1 = byte, 
TES; 


— — — —— 


2 = word, 4 = longword 


! Define the fields in the first trailer portion of the BLISS Special Cases 
i ; DST record. Also define the declaration macro. 


FreLD DSTSBLI_TRAIL1_FIELDS = 


DSTSL_BLI_VALUE = ( 0, L_ J, ! Value longword, interpreted 

aT th a to , Seatents of 
DSTSB_BLI_NAME = ( 4, B_ J, i Count byte of thes symbol name 

i Counted ASCII string 
DSTSA_BLI_TRLR2 = C 5, A_ J i The sgeend trailer starts at this 
Tes ; location + DST$B_BLI_NAME 


MACRO 
DSTSBLI_TRAILER1 = BLOCKE BYTE) FIELD(DSTSBLI_TRAIL1_FIELDS) 2; 


! Define the fields in the second trailer portion of the BLISS Special Cases 
i , DST record. Also define the declaration macro. 


FrELD DSTSBLI_TRAIL2_FIELDS = 


— — — — — ——— — — 


DSTRECROS.REQ; 1 16-SEP-1984 16:49:18.36 Page 92 


SET 
PS{SL_BL1_sIZe =({0,t.] ! Size of the Bliss data item in bytes 


MACRO 
DSTSBLI_TRAILER2 = BLOCKC BYTE) FIELD(DSTSBLI_TRAIL2_FIELDS) %; 


4 
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1 
1 
1 
' 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
byte 
: byte 
: byte 
: long 
byte 
i 
1 
1 
1 
1 
1 
1 
1 
‘ 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
F 


> ver 


: var 


THE BLISS FIELD DST RECORD 


The BLISS Field DST record describes a BLISS field ngne, BLISS field 

names are declared in FIELD declarations in hy Each BLISS field 

name is bound to an n-tuple of numbers. Usually the n-tuple, is a four- 

tuple and the numbers represent a byte or pag ee offset, the bit 

offset ——, rr: yorte or longword, the b ength of the field being 

described, pigraentens ten flag. DEBUG supports references to 

aves fields. in ais Pyocks and Blockvectors. However, a BLISS field 
an be any n-tuple. n is not 4, the field name can only be used in 

EXAMIN' commands, *, 4 in Block or Blockvector references. 


The BLISS Field DST record should not be generated for any Language 
other than BLISS. This is the format of the record: 


@ ewer erence em eer en ner ee erence —— —⸗ ù— 2 — ——————————222 


DSTSB_LENGTH ' 


————————————— ——— + 


' DSTSB_TYPE (= DSTSK_BLIFLD) ' 


Geeoeeesesussseseusunssesesoseesesceessoososoe ese eee oo ' 


: DST$B_BLIFLD_UNUSED : 


deccoececoeceesesesesosesoeessoesoneseoosesossese eeeeeo — ee ee ws ae oe ! 


H DSTSL_BLIFLD_COMPS H 


$88 09988 99809880 80088S80808SS8SRCCSS SSO COSESOSO eeeeee —— — —— — + 


' DSTS$B_Bt IFLD_NAME ' 


————— — — — — —— oot 


The Name of the BLISS Field in ASCII 
(The name's Length is given by DSTSB_BLIFLD_NAME) 


A Vector of Longwords Containing the Integer 
Values of the Components of the BLISS Field Definition 
(The number of values is given by DSTS$B_BLIFLD_COMPS) 


—— — 
—— ñ—— — — 


i Define the fields of the BLISS Field DST record. 
FIELD DSTSBLIFLD_ FIELDS = 


DST$B_BLIFLD_UNUSED = - 8. J. ! Unused=--Must Be Zero 
DSTS$L_BLIFLD- COMPS = es ! The number of components 
DST$B_BLIFLD-NAME J —1 The count byte of the field 


name Counted ASCII string 


TES; 


| 
| 
| 
| 
j 
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byte 
byte 
byte 
long 
byte 
var 
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LABEL DST RECORDS 


Labels are represented by two different DST records. A label, in the 
sense used here, is a *2* bound to an instruction address. Labels 
do not include routine, lexical block, and entry point symbols, however. 
A label can be represented by either a Label DST record or @ Label-or- 
Literal DST record. The Label-or-Literal DST record is intended only 
for Language MACRO, it appears. ‘The ni story on the origin and intent 
of this record is unclear, however.) ALl other Languages should use 
the Label DST record for (labels. 


THE LABEL DST RECORD 


The Label DST record specifies the name and address of a label in the 
the current module. A label in this sense is always bound to an in- 
struction address, not a data address. This is the DST record normally 
used for Labels in high-level languages. The DSTSL_VALUE field of this 
record contains the code address to which the label is bound. 


This is the format of the Label DST record: 


teocmae “=< e28@e@ (wR oe om Gm eh Oe Ge OS GS DH oe De ee ee ee wwe weno re wero + 


DSTSB_LENGTH 


he mm me me ee ee eeeeoe SSS SSS SSS SSSSSSSSSSSSSSSSSSSSSSSSSSGSOSSES + 


DSTSB_TYPE (= DSTSK_LABEL) 


Ne ee 2 


: Unused--Must Be Zero H 


feeeee en em emer w toe nr ecer re Sse ce Bee EDR eM ew ECE ewe eee e eee eeee eeeceoe + 


' DSTSL_VALUE ' 


ewes mwoeve env ocwm eee ewoe rete ome mre em EEE ee — —— —— — — —— — — — + 


DST$B_NAM 


¢eewr eran see eeeceoe PSPSPS SSSSSSSSSSSSSSSSSSSSSSSSSSVSSSSSSSSSSSSSGSS2ee 


The Label Name in ASCII 
(The name's length is given by DSTSB_NAME) 
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THE LABEL-OR-LITERAL DST RECORD 


[me Label-or-Literal DST record specifies the name and ** s of a 
Label ar i a code location) or the — and value of an nteger 
Literal constant). It is not cirely clear why this 
record exists § since labels can be described by Label DST records and 
integer | Lyrehis b8 con be descri oe with Standard Data DST records. 
Most Likel t recore was intended for banquege | MACRO where 
there is Little dt Set n : = *22 labels ene Peret $; one s relo- 
catable and the other that is about all. If D 
has the value DSTSK VALKIND ADDR ithe symbol is a label an zu4 it 
the value DSTSK_VALRIND_LITERAL, the symbol is a Literal. a address 
of the Label or the A of the titerat is found in the DSTSL VALUE 
field. It is recommended that high-level languages avoid this DST 
focers ane use the Label DST record or the Standard Data DST record 
nstead. 


teow wrnewee eeeceoe ù— — ———— ——— — —— ——— —— ———— —— tk 2—24 


bag) SOR OT ee 
{byte i __DSTSB_TYPE (= DSTSK_LBLORLIT) 
i byte i... vnused=-Must Be Zero! _DSTSV_VALKIND 
a CE I 
Qe SOR 
: ver 


The Label or Literal Name in ASCII 


' 

' 

— 

' 

' 

' 

' 

' 

‘ 

' 

' 

' 

J 

' 

i] 

' 

' 

4 

: This is the format of the Label-or-Literal DST record: 
' 

— 

' 

' 

— 

— 

' 

‘ 

' 

J 

' 

— 

' 

— 

— 

(The name's Length is given by DSTSB_NAME) 
' 
J 


peecoe eee eno e eee see eee ene ù— — ee 


———————-- ⸗ñ —ñ —ñ 
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THE ENTRY POINT DST RECORD 


The Entry Point DST record describes an ENTRY name in the FORTRAN or 
PL/I sense. In qther words, it describes a secondary entry point to 
the routine within which this DST record is nested. This record should 
never be generated for the main ** point to a routine since that 
entry point is already described by the Routine Begin DST record. An 
entry point described by the entey Point DST record is oeuere assumed 
to be called Fhrough the CALLS/CALLG instructions (not JSB/BSB). The 
DSTSL_VALUE field contains the address of the entry point. 


This is the format of the Entry Point DST record: 


—— — 
peated 
Rage Ee NE cs FR ne 
ea IIE Rn sn. 
ete SE EAE” A —— 
- var 


The Entry Point Name in ASCII 
' (The name's Length is given by DST$SB_NAME) 
+ 


' 
' 
! 
' 
J 
' 
J 
' 
1 
' 
' 
' 
J 
1 
4 
i] 
' Pwr — eo es ete ewes es ese meses eee omw mr secre r eee renee meen eo moms mewn} 
' 
' 
' 
' 
J 
' 
' 
' 
i] 
' 
J 
J 
i] 
' 
! 
t 
' 
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THE PSECT BST RECORD 


The PSECT DST record specifies the name, address ng Length of 
a PSECT, where a PSECT is a Program Section in the Linker sense. 
PSECT DST records are only used for honguege | MACRO were {5 18 
possible to generate code or data at the begi 33 of a 
without having any other Label on that code. BUG i lores COsect 
DST records for all other — * since high-level languages 
have other code and data labe hat are more appropriate. 


This is the format of the PSECT DST record: 


byte ; DSTS$B_LENGTH ' 
Wane er OS Tee TYPE (= DST&K-PSECT) i 
iat RACERS — — 
——— 
byte | _______DSTSB_PSECT_NARE —— ‘ 
var} DSTSA_PSECT_TRLR_BASE 

The Name of the PSECT in ASCII 

(The name's Length is given by DSTSB_PSECT_NAME) 

———— —— — Bhai st 
— — —— 


Define the fields of the PSECT DST record. 
FIELD DSTSPSECT FIELDS = 
SET 


ee ee 


DSTSB_PSECT_UNUSED = ¢- ' Unused--Must Be Zero 
DSTS$L_PSECT_VALUE = » ' Start address of the PSECT 
DST$B_PSECT_NAME = !' The coutn byte in the PSECT 


DSTSB_PSECT_TRLR_OFFS = { 7, 
DSTSA_PSECT_TRLR_BASE = C 8, 
TES; 


! Byte offset to the 

! record trailer fields 

' Base address for offset to 

: DST record trailer fields 


~ 
. 
> © oro 
tee 
ee ee) 
. 


' 

' 

' 

: name COunted ASCII 758 
PSECT DST 

' 

' 


: Define the PSECT DST record trailer fields. Also define the declaration 
! macro. 
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1 
FIELD DSTSPSECT_TRAILER_FIELDS = 
PatSLPSECT SIZE =(€0,t_. 1] ! Number of bytes in the PSECT 


MACRO 
DSTSPSECT_TRAILER = BLOCKC,BYTE] FIELD(DSTSPSECT_TRAILER_FIELDS) 2%; 


Note that the address of the PSECT DST record tailer is computed as follows: 
i DST_RECORDCDSTSA_PSECT_TRLR_BASE] + .DST_RECORDCDSTSB_PSECT_TRLR_OFFSJ 
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byte 
byte 


< 
— 


LINE NUMBER PC=¥CORRELATION 
DST RECORDS 


— — — — — 


The Line Number PC-Correlation DST record specifies the correlation 

between Listing Line numbers, as assigned by the compiler, an 

addresses. It thus the means whereby the compiler tells bEBUG where 

the generated object code for each source Line starts and how lon 

44 in ata This is the format of the Line Number PC-Correlation 
recora: 


boron ene —— — — See eee — — — — — — — — — — —— Se eee eee — — — — — 2222222— — ae ee oe Se 


i DSTSB_LENGTH 


After the two-byte header, each Line Number PC-Correlation DST record 
contains a sequence of Line Number PC-Correlation commands. Each such 
command sets or manipulates one or more state variables used by DEBUG 
in the interpretation of these commands. The main state variables are 
the current Line number and the current PC address, but there are seve- 
ral others as well. The exact semantics of the various commands are 
described in the sections that follow. 


Line Number PC-Correlation DST records are associated with the module 
within which they appear. The must thus sppeer between the Module 
Begin and the Module End DST records for the current module. There are 
no further restrictions on where they may appear, however. In particu- 
lar, they need not be nested within the routines or lexical blocks that 
they describe. It is thus legal to generate all Line Number PC-Corre- 
lation DST records for a module after the last Routine End DST record, 
for instance. These records can also be interspersed between Routine 
and Block Begin and End records in any way convenient for the compiler 
implementer. However it is done, DEBUG treats them as belonging to the 
module as a whole. 


The Line Number PC-Correlation information may be spread over as many 
DST records as necessary. No Line Number PC-Correlation command may be 
broken across record boundaries, but otherwise the Line Number PC-Corre- 
lation DST records within a module are considered to constitute a single 
command stream. The Continuation DST record may not be used to continue 
Line Number PC-Correlation DST records. 
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: Define the fields of the Line Number PC-Correlation DST record. 
FIELD DSTSLINE_NUM_FIELDS = 
Fee ee FAM PATA =(€ 2, A. ] ! Start address of PC-correlation data 


LINE NUMBER PC-CORRELATION COMMANDS 


Each PC-Correlation command consists of a command byte possibly fol- 
lowed by a parameter byte, word, or longword. The presence, size, and 
meaning of the parameter field is determined by the command byte. This 
illustration summarizes the structure of one command: 


+ eeeeeoe =e wee wr rr ere ree roe — — — eer ee eee Be em wm Bw wm mer — — — wm — — — 2 2— ee a = + 


COMMAND _BYTE 


i byte 


i var 
Zero or One Parameter Field 


(Byte, Word, or Longword) 


4 


The command byte contains a command code. If this command code is 
negative, this is a Delta-PC command. A Delta-PC command specifies 
by how * bytes to increment the PC to get to the start of the 

next Line (see detailed description below). This byte count is en- 
coded Steectiy in the command byte: If the command code is negative, 
its negative is the PC increment. The Delta-PC command has no param- 
eter field. If the command code is positive, it specifies some other 
command as described below. In this case, there may be a parameter 
field, depending on the command code. 


i Define the command codes allowed in Line Number PC-Correlation commands. 
! If the command code is zero or negative, the command is a poenpyte Delta-PC 
! command. Here we define the command-code range for the Delta-PC command. 


LITERAL 
DST$K_DELTA_PC_LOW 
DSTS$K~DELTA_PC—HIGH 


' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
L 


= -128, ' The lower bound on Delta-PC commands 
= 0; ! The upper bound on Delta-PC commands 


! Define the PC-correlation command codes other than the Delta-PC command. 
} These command codes are always positive. 


LITERAL 


—_— — — —ñ— ñ ——— — — — — — — — — — 


f 
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DSTSK_DELTA_PC_W = 1 ! Delta=-PC Word command 
DSTSK-DELTA~PC-L = 17, | Delta-PC Longword command 
DSTSK_INCR_CINOM = ¢: ! Increment Line Number Byte command 
DSTSK_INCR_LINUM_W = ! Increment Line Number Word command 
DSTSK_INCR_LINUM_L = 18, | Increment Line Number Longword command 
DSTSK_SET_CINUM_INCR = 4, ' Set Line Number Increment Byte command 
DSTSK_SET LINUM_INCR W = 5, ! Set Line Number Increment Word command 
DSTSK_RESET_LINOM_INCR = g. ! Reset Line Number Increment command 
DSTSK_BEG_STMT_MODE =f, : pean Statement Mode command 
DSTSK_END_STMT MODE = 8 ! End Statement Mode command 
DSTSK-SET-STMTAUM = 18, | Set Statement Number Byte command 
DSTSK_SET_LINUM_B = 19,  ! Set Line Number Byte command 
DSTSK_SET_LINUM =9 ! Set Line Number Word command 
DSTSK-SET—L INUM_L = 26, {| Set Line Number Longword command 
DSTSK_SET_PC = 10, ! Set Relative PC Byte command 
DSTSK_SET_PC_W = 11, ! Set Relative PC Word command 
DSTSK_SET_PC_L = 12, ! Set Relative PC Longword command 
DSTSK_SET ABS_PC = 16, ! Set Absolute PC Longword command 
DSTSK_TERA = 14, ! Terminate Line Byte command 
TSK_TERM_W = 15, ! Terminate Line Word command 

DSTSK_TERM_L = 21, Terminate Line Longword command 
DSTSK_PCCOR_LOW = -128, ! Smallest value allowed in the first 

: byte of a PC-correlation command 
DSTSK_PCCOR_HIGH = 21; ! Largest value allowed in the first 

: byte of a PC-correlation command 


byte 


byte 
byte 


byte 
word 


byte 
long 


The parameter field, if present, contains an unsigned byte, unsigned 
word, or longword value. The possible PC-Correlation command formats 
thus look as follows: 


eer sees em ee wee eee ee ween nr eee res eee ew eee mene meee em meen eo em ee emo ce + 


: COMMAND _BYTE \ 


gor eeeneceececnmaae ù em eter n en ee een DEO ee Teton een meen ono eee + 


: NEXT_UNS_BYTE (Unsigned Byte Value) : 


power eon ees mame es See Dm ewe Em em OM EE BEE BER OO ORO BROMO OE BOE MOD EO Oe + 


Geer 2— Seecerrsesroroesoes ns acee — eon oanmase SO wo eS me a ee oe + 


COMMAND _BYTE ; 


toon eanunae See S ror moa neswonsoenuocace moe Vo nena e SOO Se ne Dee Se mee we oo + 


NEXT_UNS_WORD (Unsigned Word Value) ' 


¢ewesceerereoenaen we ee seneantecosecoe — rtoaamovreanmacenraenmenraca oem newman we > 


tem mom ocnoa me ù — OOS OOOOH EERE MONO OE ERS OE OM + 


: NEXT_UNS_LONG (Longword Value) : 
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9 OOO OO O66 6666S SSS SSS SSS SSS SSSSSSSSSSSSHSSSSSSSSESSSESESEEECOEESEESS — 


PC-CORRELATIOM COMMAND SEMANTICS 


The individual ——— are described separately below. To clarify what 
these commands actual l do, each is followed by a veraet semantic de- 
scription using BLISS-like pseudo-code. This description. show what the 
command does to a number of state variables used by EBUG en inter- 
preting these commands. The state variables are the following: 


CURRENT_LINE == The current Line number. 

CURRENT_STMT — The current statement number. 

CURRENT_INCR == The current Line number increment. 

CURRENT_STMT_MODE == The statement mode flag; set to TRUE when 
statement mode is set, set to FALSE otherwise; 

START_PC -- The start address of the lowest-address routine 
in the current module; 

CURRENT_PC == The current PC value code address). 

CURRENT_MARK == * Line-open/Line-closed flag; set to LINE_OPEN 
when Line numbers are being defined and set to 

LINE_CLOSED when a routine has been terminated 

aad New Lines are not being defined. 


The initial values of these state variables when the PC-Correlation 
commands for a given module are interpreted are as follows: 


CURRENT_LINE = 0; 

tl “STMT = i; 

CURRENT ~INCR 

CURRENT “STMT movi = FALSE; 

START_PC = Start address of the lowest-address 
routine in the current module; 

CURRENT_PC = STAR 


ART PC; 
CURRENT-MARK = LINE_CLOSED; 


The sections below describe the format and semantics of each of the 
individual PC-Correlation commands. 


THE DELTA-PC COMMAND 


This command defines a correlation between a Line nor and a PC value. 
The current Line number is incremented by the current increment value 
cape A 1) one the current PC value is” incremented by the ne ative of 
the command byte. The resulting Line number then has the resulting PC 
value. In other words, both the Line number and the PC value are incre- 
mented before the correlation is established. The PC increment value 
(the negative of the command code) thus specifies how aony bytes to go 
forward to get to the start of the Line being defined. ese are the 
formal semantics of the command: 


———— e —ñ — 
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IF CURRENT _STMT_MODE 

CURRENT_STMT = CURRENT_STMT + 1 
_ CURRENT_LINE = CURRENT_LINE + CURRENT_INCR; 
CURRENT_PC = CURRENT PC = PC_COMMANDCCOMMAND_BYTE); 
CURRENT-MARK = LINE_OPEN; 


The value of CURRENT _PC now contains the start address of the Listing 
Line specified by the values of CURRENT_LINE and CURRENT_STMT. Note 
that Line-open mode is now set. 


THE DSTSK_DELTA_PC_W COMMAND 


This command is Like the normal Delta-PC command except that the PC 
increment value is given in an unsigned word following the command 
code. These are the semantics: 
IF CURRENT_STMT_MODE 
CURRENT_STMT = CURRENT_STMT + 1 
CURRENT_LINE = CURRENT_LINE + CURRENT_INCR; 
CURRENT_MARK = LINE_OPEN; 


EN; 
CURRENT_PC = CURRENT_PC + PC_COMMANDCNEXT_UNS_WORD); 


The value of CURRENT_PC now contains the start address of the Listing 
Line specified by the values of CURRENT_LINE and CURRENT_STMT. Note 
that Line-open mode is now set. 


THE DST$K_DELTA_PC_L COMMAND 


This command is Like the normal Delta-PC command except that the PC 
increment value is given in an unsigned longword following the command 
code. These are the semantics: 

ul CURRENT_STMT_MODE 


CURRENT_STMT = CURRENT_STMT + 1 


CURRENT_LINE = CURRENT_LINE * CURRENT_INCR; 
CURRENT_MARK = LINE_OPEN; 
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CURRENT_PC = CURRENT_PC + PC_COMMANDCNEXT_UNS_LONG); 


The value of CURRENT_PC now contains the start address of the Listing 


Line specified by the values of CURRENT_LINE and CURRENT_STMT. Note 
that Line-open mode is now set. 


THE DSTSK_INCR_LINUM COMMAND 


This command increments the current Line number by the value given in 
the unsigned byte following the command code. If statement mode is set, 
the current statement is reset to 1 as well. These are the formal 
semantics of the command: 


CURRENT LINE = CURRENT LINE + PC_COMMANDCNEXT_UNS_BYTEJ; 
IF CURRENT_STMT_MODE TREN CURRENT_STMT = 1; 


THE DSTSK_INCR_LINUM_W COMMAND 


This command increments the current Line number by the value given in 
the unsigned word following the command code. If statement mode is set, 
the current statement is reset to 1 as well. These are the formal 
semantics of the command: 


CURRENT LINE = CURRENT LINE + PC_COMMANDCNEXT_UNS_WORD); 
IF CURRENT_STMT_MODE TREN CURRENT_STMT = 1; 


THE DSTSK_INCR_LINUM_L COMMAND 


This command increments the current Line number by the value given in 

the unsigned longword following the command code. If statement mode is set, 
the current statement is reset to 1 as well. These are the formal 

semantics of the command: 


CURRENT LINE = CURRENT LINE + PC_COMMANDCNEXT_UNS_LONG); 
IF CURRENT_STMT_MODE TREN CURRENT STMT = 1; 


THE DSTSK_SET_LINUM_INCR COMMAND 


This command set the current Line number increment value to the value 
specified in the unsigned byte following the command code. If state- 


ee ——— — — — — — — — — — eee ee ee ee ee ee ee te 
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ment mode is set, the current statement number is set to 1. These are 
the formal semantics of the command: 


CURRENT _INCR = PC_COMMANDCNEXT_UNS BYTE); 
IF CURRENT STMT_MODE THEN CURRENT_STMT = 1; 


THE DSTSK_SET_LINUM_INCR_W COMMAND 


This command set the current Line number increment value to the value 
specified in the unsigned word following the command code. If state- 
ment mode is set, the current statement number is set to 1. These are 
the formal semantics of the command: 


CURRENT_INCR = PC_COMMANDCNEXT_UNS_WORD); 
IF CURRENT_STMT_MODE THEN CURRENT_STMT = 1; 


THE DSTSK_RESET_LINUM_INCR COMMAND 


This command resets the current Line number increment value to 1. If 
statement mode is set, the current statement number is set to 1 as well. 
These are the semantics: 


CURRENT _INCR = 1; 
IF CURRENT_STMT_MODE THEN CURRENT_STMT = 1; 


THE DSTSK_BEG_STMT_MODE COMMAND 


This command sets statement mode, meaning that subsequent Delta-PC com- 
mands will increment the current statement number within the current 
Line and not the current Line itself. This command is only allowed in 
the Line-open state. Statement mode can opt tonal ly be used by languages 
that have multiple statements per line. This command also set the cur- 
rent statement number to 1. These are the semantics: 


IF CURRENT _MARK NEQ LINE_OPEN THEN SIGNAL(Invalid DST Record); 
CURRENT _STAT_MODE = TRUE? 
CURRENT"STMT™= 1; 


THE DSTSK_END_STMT_MODE COMMAND 
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This command clears statement mode so that that subsequent Delta-PC com- 
mands will again increment the current Line number, not the statement 
number. The —— also set the current statement number to 1. These 
are the semantics: 


CURRENT_STMT_MODE = FALSE; 
CURRENT-STMT~= 1; 


THE DSTSK_SET_LINUM_8 COMMAND 


This command sets the current Line number to the value specified in the 
unsigned byte that follows the command code. These are the semantics: 


CURRENT_LINE = PC_COMMANDCNEXT_UNS_BYTE); 


THE DSTSK_SET_LINUM COMMAND 


This command sets the current Line number to the value specified in the 
unsigned word that follows the command code. These are the semantics: 


CURRENT_LINE = PC_COMMANDCNEXT_UNS_WORD); 


THE DSTSK_SET_LINUM_L COMMAND 


This command sets the current Line number to the value specified in the 
Longword that follows the command code. These are the semantics: 


CURRENT_LINE = PC_COMMANDCNEXT_UNS_LONG]; 


THE DSTSK_SET_STMTNUM COMMAND 


This command sets the current statement number to the value specified 
in the unsigned word that follows the command code. The command should 
only be used when statement mode is set. These are the semantics: 


CURRENT _STMT = PC_COMMANDCNEXT_UNS_WORD]; 
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THE DSTSK_SET_PC COMMAND 


This command sets the current PC value to be the value specified in the 
ene tpree byte following the command code added to the start address of 
the lowest-address routine in the current module. This command is only 
allowed in the Line-closed state. [hese are the formal semantics: 


If CURRENT_MARK NEQ LINE CLOSED a SIGNAL(Invalid DST Record); 
CURRENT_PC™= START_PC + PC_COMMANDCNEXT_UNS_BYTE); 


THE DSTSK_SET_PC_wW COMMAND 


This command sets the current PC value to be the value specified in the 
unsigned word following the command code added to the start address of 
the lowest-address routine in the current module. This command is only 
allowed in the Line-closed state. These are the formal semantics: 


IF CURRENT_MARK NEQ LINE CLOSED THEN SIGNAL(Invalid DST Record); 
CURRENT_PC”= START_PC + PC_COMMANDCNEXT_UNS_WORD); 


THE DSTSK_SET_PC_L COMMAND 


This command sets the current PC value to be the value specified in the 
longword following the command code added to the start address of the 
lowest-address routine in the current module. This command is only 
allowed in the Line-closed state. These are the formal semantics: 


IF CURRENT_MARK NEQ LINE_CLOSED THEN SIGNAL(Invalid DST Record); 
CURRENT_PC"= START_PC + PC_COMMANDLNEXT_UNS_LONG); 


THE DSTSK_SET_ABS_PC COMMAND 


This command sets the current PC value to be the absolute address speci- 
fied in the Lonpyere following the command code. This command is only 
allowed in the Line-closed state. These are the formal semantics: 


1F CURRENT MARK NEQ LINE CLOSED THEN SIGNAL Invalid DST Record); 
CURRENT_PC~= PC_COMMANDCREXT_UNS_LONG); 


THE DSTSK_TERM COMMAND 
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This command terminates the PC-Correlation command sequence for the 
current routine or other program unit and specifies the number of bytes 
in the last 390 specified by a Delta-PC command. Since the Delta-PC 
command specifies how many — precede the Line being defined, the 
Terminate command is needed to say how * bytes are in that Line 
(i.e., how many bytes will increment the PC to the first byte past the 
current program unit). The number of bytes in the last Line is speci- 
fied by the unsigned byte following the command code. This command also 
sets the Line-closed state. These are the semantics of the command: 


CURRENT_PC = CURRENT PC + PC_COMMANDCNEXT_UNS_BYTE); 
CURRENT“MARK = LINE_CLOSED; 


THE DSTSK_TERM_W COMMAND 


This command terminates the PC-Correlation command sequence for the cur- 
rent routine or other program unit and specifies the number of bytes in 
the Last Line of that program unit. It is a variant of the DSTSK_TERM 
command described above. The number of bytes in the Last line is speci- 
fied by the unsigned word following the command code. This command also 
sets the Line-closed state. These are the semantics of the command: 


CURRENT_PC = CURRENT_PC + PC_COMMANDCNEXT_UNS_WORD]; 
CURRENT“MARK = LINE_CLOSED; 


THE DSTSK_TERM_L COMMAND 


This command terminates the PC-Correlation command sequence for the cur- 
rent routine or other program unit and specifies the number of bytes in 
the Last Line of that program unit. It is a variant of the DSTSK_TERM 
command described above. The number of bytes in the last line is speci- 
fied by the longword following the command code. This command also sets 
the Line-closed state. These are the semantics of the command: 


CURRENT_PC = CURRENT PC + PC_COMMANDCNEXT_UNS_LONG); 
CURRENT“MARK = LINE_CLOSED; 


END OF LINE NUMBER PC-CORRELATION DST RECORD DESCRIPTION. 
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byte 
byte 
var 
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SOURCE FILE CORRELATION 
DST RECORDS 


The Source File Correlation DST record is used to specify the correla- 
tion between Listing Line numbers on the one hand and source files and 
source file record numbers on the other. These records enable DEBUG 
to display source Lines during the debugging session. 


The Source File Correlation DST record has the following format: 


$0 6006S 6S SSS SSS SSS SS SSS SS SSSSSSSSSSSSSSSESSEESSSESSESESEOOOEESS 


' DSTS$B_LENGTH 


$e mee nw woo wme an aeanmaemeaer nwo roca nec eee eeecee — r esteem none e ee mee ewer ee} 


‘ DSTSB_TYPE (= DSTSK_SOURCE) 


Feeeee ee eee eee eee eeeeeeeeeeeeeseeeeeeeeeseoesecoeoaeseeea eeeceeeoe = 


A variable number of 
Source File Correlation commands 


5 


—EE 


Sewer wm —— 2 — — — — — — — — — — — — 2 — — —— —222224 


After the Length and DST type bytes, the record consists of a sequence 
of Source File Correlation commands. These commands specify what source 
files contributed source Lines to this module and how the module's List- 
oy Line numbers are Lined up with the source files and record numbers 
within those source files. The available commands are described indi- 
vidually below. 


If the Source File Correlation commands needed to fully describe the 
current module will not fit in a single Source Line Correlation DST 
record, they can be spread over any number of such DST records. These 
records will be processed epquent Sat ly. in the order that they appear, 
until there are no more such records for the current module. 


The purpose of the Source File Correlation commands is to allow DEBUG 
to construct a table of correlations between Line nuayers and source 
records. A “‘Line number” in this context means the Listing Line num- 
r. This is the Line number which is printed in the progres Listin 
and is oytous to the PC-Correlation DST records by the comp ler. (PC- 
Correlation DST records corretete Listing ine numbers with Program 
Counter values.) A corresponding source Line is identified by wo 
things: a source file and a record number within that source file. 


The semantics of the Source File Corretas ton commands can be understood 
in terms of aenipulet ng three state variables and issuing one command. 
The three state variables are: 


LINE_NUM == The current Listing Line number. 
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SRC_FILE == The File ID of the current source file, 
i.e. a —— integer uniquely defining 
the source file. 

SRC_REC <== The record number (in the RMS sense) in 
the current source file of the current 
source Line. 


LINE NUM is assumed to have an initial value of 1 while SRC_FILE and 
SRC_REC are initially undefined. The one command is: 


DEFINE(LINE_NUM, SRC_FILE, SRC_REC) 


This command declares that Line number LINE_NUM is associated with the 
source Line at record number SRC_REC in the file specified by SRC_FILE. 


Given this, the compiler must —V a ce of Source File Correla- 
tion commands which cause LINE NUM, SRC_FILE, and SRC_REC to be set up 
appropriately and which cause the proper DEFINE operations to be issued 
to allow DEBUG to generate the correct Line number to source record 
correlation table. (DEBUG may not ye generate the full table, 
but it must be able to generate any part of such a table it needs.) 

The semantics of each Source File Correlation command is described 
below in terms of these state variables and commands. 


Line numbers must be DEFINEd in sequential order, from lowest Line 
number to highest Line number, in the Source File Correlation commands 
for one module. The source records these Line numbers correlate with 
may be in any srder. of course. 


It should be clear from what follows that the source for one module may 
come from many source files. This can be caused + plus-lists on the 
compiler command (e.g., SFORTRAN/DEBUG A+B+C) and by INCLUDE statements 
in the source. Also, source Lines may come from modules within source 
libraries as well as from independent source files. 


Form feeds in source files, or more precisely source file records which 
contain nothing but a single form feed (CNTL=L) character, are counted 
as individual sources lines in some senguepes but are ignored (not as- 
signed line numbers) in other languages. DEBUG will handle either con- 
vention, but DEBUG's default behavior is that form feed records are 
ignored in sources files. They are not displayed and they do not count 
toward the source file record number of subsequent source records. To 
— DEBUG count such records, the DSTSK_SRC_FORMFEED command must be 
used. 


Define the location of the first command in the DST record. 
IELD DSTSSOURCE _FIELDS * 
PS TSA_SRC_FIRST_ CAD = ( 2, A_ J] ! Location of first command in record 


' 
i 
i 
i 
i 
i 
i 
i 
i 
; 
i 
i 
; 
i 
F 


! Define the command codes for all the Source File Correlation commands. 


— — ———————— ————— ————— — — — — — — — — 
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1 

LITERAL 

Minimum command code for uth ran 
Declare a source file for this aos ule 
Set the current source file (word 

Set source record number (Lon oh 
Set source record number (word) 

Set Listing Line number (lLongword) 
Set = 390 number (word) 
Increment listing Line number (byte) 
Unused=mavel abit for future use 
Unused--available for future use 
Define N separate Lines (word) 

Define N separate Lines (byte) 
Unused--available for future use 
Unused--available for future use 
Unused--available for future use 
Unused--available for future use 
Count Form-Feeds as source records 
Maximum command code for CASE ranges 


tmt20---OO----GCOCCVCVCCC9 
“ynnuounouwe 


DSTS$K -SRC_FORMFEED 
DSTSK_SRC"MAX_CMD 


— —2— — — — — — 


AOo——- 


! Define the fields of the Source Line Correlation commands. Also define the 
: corresponding declaration macros. 


FIELD DSTSSRC_COMMAND_F IELDS = 
1 
Field common to all Source File Correlation commands. 


DST$B_SRC_COMMAND ={0, 6.1], ! Command code 
The fields of the Declare Source File command. 
DST$B_SRC_DF_LENGTH =(€1, 8. ]. ' Length of this command 
DST$B_SRC_DF_FLAGS = e 8. de ! Flag bi Foro tetetved (MBZ) 
DSTSW_SRC_DOF _FILEID » o WM de ! Source file's File ID 
DST$Q_SRC_DF_RMS_CDT = » A, Je ! Creation date and time or mod- 
; ule insertion date and time 
DSTSL_SRC_DF_RMS_EBK = 13. L_ J]. ! End-of-File block number 
DSTSW_SRC_DF_RMS_FFB =(€ 17, WJ. ! First Free Byte in EOF block 
DSTSB_SRC_DF_RMS_RFO =(€ 19, 8B. J, ! Record and File Organization 
DSTSB_SRC"DF-FILENAME = [( 20, B- J, ! Source file name counted ASCII 
DSTSA_ SRC“DF-FILENAME = [( 21, A_ J, ! (count byte, string addr) 


7 Fields used to access information in all other commands. 
DSTSL _SRC_UNSLONG = 4 ! Unsigned longqword parameter 


DST$W_SRC_UNSWORD 1, wo } i Uns igned — parameter 
os 188. SRC_UNSBYTE i Unsigned byte parameter 


. Declare trailer field in the Declare Source File command. 
FIELD DSTSSRC_DECLFILE_TRLR_FIELDS = 


eo ee 
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SET 
312 C_OF _L IBMODNAME 4 9. 8 - }: ! Module name counted ASCII 
Dba C=DF-LIBMODNAME = : (count byte, string addr) 


: Declaration macros for Source File Correlation command and trailer blocks. 


DSTSSRC_COMMAND = BLOCK(,BYTE rigt (DSTSSRC_COMMAND FIELDS) %, 
DSTSSRC"CMDTRLR = BLOCKC,BYTE (DSTSSRC_DECLFILE_TRLR_FIELDS) 2%; 


DSTRECRDS.REQ; 1 


byte 
byte 
byte 
word 
quad 
long 
word 
byte 
var 


var 
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DECLARE SOURCE FILE (DSTSK_SRC_DECLFILE) 


This command declares a source file which contributes source Lines to 
the current module. It declares the name of the file, its creation 
date and time * yarious other attributes. The command also assigns 
a one-word "file to this source file. This is the format of the 
Declare ane — command: 


geese m ero ene ewe ee em meen mm em een eco mew were nr ee mone mean we eeeeoe come aasn een + 


‘ DBGSB_SRC_COMMAND (= DSTSK_SRC_DECLFILE) ' 


kaw eee — —— — —— — — 22— — — 2 22—— — 2 —— — — Tew Bees BeBe een Bae + 


H DSTSB_SRC_DF _LENGTH ' 


Gceoceeeseousseseseoescesoueseceseesesousosesesoese eeeeeoe esSeeeeaeoe + 


: DSTSB_SRC_DF_FLAGS ' 


— —— — —— ü—————— ———22— — 


DSTSW_SRC DF -FILEID ' 


Geese ue meee ene ce — — —— — —22 eeeceoe See eee — — — — — — — — —2 —2 — enema nme + 


: DSTSa SRC “OF “RMS _ CDT ' 
H DSTSL_SRC_DF _RMS_EBK ' 


—— ù————————————————2——— ù————————— — — 


DST$W_SRC_DF_RMS_FFB ; 
DST$B_SRC_DF_RMS_RFO ; 


beer ee een erence wer — — rawr woe nr BB ae tDemeen Beene neem e wre enna weewn weno ea ame oe 


DST$B_SRC_DF _F ILENAME } 


tone wee me me (ee om me oe me oe oe mee me en oe (eS EA we ee ee mw — eee e+ 


DST$B_SRC_DF_LIBMODNAME 


¢ ewer ewer ere eenewe SOE Be EON ODOM Dee eee eee ete ewe we ere mew een ene + 


The fields in this command are the following: 


DSTSB_SRC_DF_LENGTH = The Length of this command, i.e. the number of 
bytes remaining in the command after this field. 


DSTSB_SRC_DF_FLAGS - Bit flags. This field is reserved for future use. 
At present this field Must Be Zero. 


DSTSW_SRC_DF_FILEID = The one-word ‘File ID’' of this source file. This 
File ee which can Later be used in the Set File command, is 
4A. unique number which the compiler assigns to each source 
file catch | contributes source pees, to the current module. Each 
source file thus has a number (the File ID) and is identified by 
that number in the Set File (DSTSK. SRC_SETFILE) command. 


DST$Q_SRC_DF ~RAS CDT = The greetton date and time of this source file. 
This” gua Gword quantity should be retrieved with a SXABDAT 
extended attribute block from RMS via the SOPEN or SDISPLAY 
system service. The creation date and time should be taken 
from the XAB$Q_CDT field of the XAB. 


If the source file is a module in a source library, this field 
should contain the module's lacort ten Date and Time in the Lib- 


F 
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. 
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. 


rary. This value should be retrieved with the LBRSSET_MODULE 
Librarian call. The Library file's creation date is not used. 


DSTSL_SRC_DF -PMS BK = The End-of-File block number for this source 
tTle. s Longuoré quantity should be retrieved with a 
SKASENC. ae, attibute block from RMS via the SOPEN or 
SDISPLAY system service. The End-of-File block number should 
be taken from the XABSL -EBK field of the XAB. 


This field should be zero for modules in source Libraries. 


DSTS$w_ ome zef RMS_FFB = The first free byte of the End-of-File block 
r this source file. This word quant ty should be retrieved 
2 A SXABFHC extended attribute block from RMS via the $SOPEN 
or $DISPLAY system service. The first free byte value should 
be taken from the XABSW_FFB field of the XAB. 


This field should be zero for modules in source Libraries. 


DSTSB_SRC_DF_RMS_RFO = The file organization and record format of this 
source file. This byte value should be retrieved with a 
SXABFHC extended attribute block from RMS via the SOPEN or 
SDISPLAY system service. The file organization and record 
format should be taken from the XABSB_RFO field of the XAB. 


This field should be zero for modules in source Libraries. 


DST$B_ ™. 5 FILENAME = The full filename of the source file. This is 

Re Tully specified — complete with device name and 
— number, in which all wild cards and logical names have 
been resolved. This 2 SOPe should be retrieved with a SNAM 
block from —* Pe the SOPEN or $SEARCH System service. The 
Sos tres eptrina —* Resultant String’’ specified by the 

SL_R S, and NAMSB_RSL fields 3 the SNAM block. 
on the Ae ite — 3 represented as a Counted ASCII string (a 
one-byte character count followed by the name string). 


DST$B_ 8* —* LIBMODNAME - The yource Binoy Fp. rig ty name (if applicable) 
the null string. If the sour octually 3 sodule in 

J source library, the DST$B_ gre _DF _FTLENARE 38* aa the 
filename of the source Library and the DST$B_SRC_D  LTMODNAME 
field gives the name of the source module mit the that library. 
If the source file does not come from a source library, this 
field (DST$B_SRC_DF_LIBMODNAME) contains the null (zero-Length) 
string. This fiéld is represented as a Counted ASCII string. 
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SET SOURCE FILE (DSTSK_SRC_SETFILE) 


This command sets the current source file to the file denoted by the 
one-word file ID given in the command. The set file is then fhe file 
ren which further source Lines are taken when the correspond ng list- 
ing Lines are defined. This is the format of the command 


dew meme nme mm mer ee ee meee eee ten ee Oe em mm em em eee CO oem e mew emecomanest 


‘ byte | DBGSB_SRC_COMMAND (= DSTSK_SRC_SETFILE) H 


õC—» ———— 


i word { DST$W_SRC_UNSWORD: The File ID of the desired source file } 


——— —————— —— — ee eeeee me meh 
The semantics of this command is: 
SRC_FILE file ID from command 


' 

' 

' 

— 

' 

— 

' 

' 

— 

' 

' 

‘ 

' 

' 

— 

— 

' 

: SRCTREC set to current source record for this 
: source file 
' 
' 
' 
' 
' 
' 
' 
— 
' 
' 
' 
— 
' 
' 
' 
— 
— 
' 


SET SOURCE RECORD NUMBER LONG (DSTSK_SRC_SETREC_L) 


This command sets the current source file record number to the longword 
value specified in the command. Its format is: 


i Peewee wer een sre mene sneer ne monn oanr ener aasee= Se ee eeeeeeoeoenee See eeeoneanoonaneanee + 
' byte : DBG$B_SRC_ COMMAND (= DSTSK_SRC -SETREC a? : 
i Long i ____DSTSL_SRC_UNSLONG: “The desired new source record number i 
The semantics of this command is: 
SRC_REC := longword value from command 
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byte 
word 


byte 
long 


SET SOURCE RECORD NUMBER WORD (DSTSK_SRC_SETREC_wW) 


This command set the current source file record number to the word 
value specified in the command. It is thus a more compact form of 
the DSTSK_SRC_SETREC_L command. Its format is: 


terme seme meee omen arma r rae ete rn meme eter menmeroe en ewonoecoa} 


DBGSB_SRC_COMMAND (= DSTSK_SRC_SETREC_w) ; 


See ee eee eee ee ee SSeS ee SeSSSeSSSSSeeeseeeseseoesesesececsoaoaoseoan + 


‘ DSTSW_SRC_UNSWORD: The desired new source record number H 
The semantics of this command is: 
SRC_REC := word value from command 


SET LINE NUMBER LONG (DSTSK_SRC_SETLNUM_L) 


This command set the current Listing Line number to a longword value 
specified in the command. Its format is: 


teeecw cer remo r nem ernr ec een esac ee -seeeeoe Seen nwrmowre eww mee eceee ewe — eee eee 


DBGSB_SRC_COMMAND (= DSTSK_SRC_SETLNUM_L) 


ce re Se ee eeeeeeoeeeenene eeecee + 


: DSTSL_SRC_UNSLONG: The desired Listing Line number : 


$e wmoe nen ne aan > ooo i oo ee em eo $ 


The semantics of this command is: 
LINE_NUM := Longword value in commmand 
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byte 
word 


byte 
byte 


SET LINE NUMBER WORD (DSTSK_SRC_SETLNUM_w) 


This command sets the current Listing Line number to a one-word value 
specified in the command. Its format is: 


00066065606 C COSC SOS S SS SESS SSSSSOSSSSSSSHSSSSSSSSSSSeeeeeees} 


H DBGSB_SRC_COMMAND (= DSTSK_SRC_SETLNUM_W) ' 


Peocoeecocecoewcosooesooceseosquccecoesoossooccecoscoescecosecce} 


H DSTSW_SRC_UNSWORD: The desired Listing Line number : 


—2ÿ 4 


The semantics of this command is: 
LINE_NUM := word value in command 


INCREMENT LINE NUMBER BYTE (DSTSK_SRC_INCRLNUM_B) 


This command increments the current eben Line number by a one-byte 
value specified in the command. Its format is: 


Fewer reece eo eer econ ewen ean see eeoeoeee See ee eee eeeneoeoenoneneceo See eeeeenoeenenoeneeo * 


DBGSB_SRC_COMMAND (= DSTSK_SRC “INCRLNUM_ B) ' 


teow em ern newer rencererecce — — — —222 —22—— — 22—— 2224 


i DSTSB_SRC -UNSBYTE: The desired Listing Line number increment 4 


— — ———— —— ù— 2 2 2—— 2 — — 2 — — — 2 —2 2— 22 — 


The semantics of this command is: 
LINE_NUM := LINE_NUM + byte value in command 
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byte 


COUNT FORM-FEEDS AS SOURCE RECORDS (DSTSK_SRC_FORMFEED) 


This command Sepenr tee that DEBUG should count source —2 which 
cere iete of nothing but a Form-Feed gherecter tty 


are not considered to be iho ceesteas Lines; instead 


to them and DEBUG mh... then — 2* ore —* displayed 
as * of the source and they do not contribu x3 © source Vrecoré 
ay Pe qourse files. However, if the DSTSk_ 
is specified in the Source File Correlat on DST Record * a module, 
displayed and 


If used, this command must appear before any commands that actually 
define source lines. Making it the first command in the first 
Source File Correlation Record for the module is a eens choice. 


¢ eww emote mmm ewer emo ewe emo ew omen momo mcm mm eee emer moe ee oe ewe ee wee wm eee ewe + 


' DBGSB_SRC_COMMAND (= DSTSK_SRC_FORMFEED) ' 


ö—— — ——2ÿ —4 


The semantics of this command is to set a mode flag which says to 
count Form-Feed records as normal records. The default behavior 
is to ignore Form-Feed records. 
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byte 
word 


byte 
byte 
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DEFINE N LINES WORD (DSTSK_SRC_DEFLINES_w) 


This command defines the squree file and sourse * numbers for 
a coats fied number of Listing Line numbers. The specified num 8 is 
given by a one-word count in the command. The command format 


+ eSreor eee Sef 2 fs ewes ee — — nee se TTB OSHS BETZ EFR2ene2naenwenmwenannwaocasewzesesewrnaa a + 


DBGSB_SRC_COMMAND (= DSTSK_SRC_DEFLINES_W) ' 


eeeeeeesoccoscosesoscoosesesoosessoeseoosoooscosescsoesosececcs$ 


: DSTSW_SRC_UNSWORD: The number of Lines to define ; 
The semantics of this command is: 
DO the number. of times specified in the command: 
DEF INE (LINE NUM, SRC FILE, SRC_REC); 
LINE NUM :="LINE_NUM™+ 1; 
* REC := SRC NREC + 1; 


DEFINE N LINES BYTE (DSTSK_SRC_DEFLINES_B) 


This command defines the source file and source record number for 

a specified —— 3 et ine Line numbers. The specified number is 
given by a one eyte in the command. This is thus a more compact 
orm of the DsT$ “Ere OOEFLINES _W¥ command. Its format is: 


dw See ee —— —— — —— we we Bee em > 


‘ DBGSB_SRC_COMMAND (= DSTS$K_SRC ~DEFLINES 8) ' 


tearm ee ene —— —— —— —— — eeeee —————— ⏑üüü ———— + 


: DSTSB_SRC_UNSBYTE: The number of Lines to define : 


wre rewnwrnsre me wre er een enw eer wrmeocr ema waren ceeroee See e eee eee + 


The semantics of this command is: 


DO the number of times specified in the command: 
DEF INE (LINE NUM, SRC FILE, SRC_REC); 
LINE NUM :="LINE_NUM™+ 1; 
65 REC := SRC REC ¢ 1; 


i END OF SOURCE FILE CORRELATION DST RECORD DESCRIPTION. 
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' 
i 
; 
f 


byte 
byte 
byte 
Long 
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THE DEFINITION LINE NUMBER 
DST RECORD 


NOTE: THIS DST RECORD 1S NOT SUPPORTED BY DEBUG V4.0. 


The Definition Line Number DST —* specifies the Listing Line number 
at which a data symbol or other object is defined or declared. The 
intent is to make use of this information in future DEBUG commands so 
that a veer con ee the declaration source line for t specified symbol. 
The Definition Line Number DST record must immediately follow the data 
pst record of the data object whose Line of definition is being speci- 


This is the format of the Definition Line Number DST record: 


¢mow ewer own ee wm en merece ence eee nmowm ao wr nn retrwenrcr ocean enw eene eSeeeoeaneee + 


DSTSB_LENGTH (= 6) 


Fer e ween wre eee m meme eee eee een ew eee emer mee ew ere m emcee woe mee we monmooeonane + 


DST$B_TYPE = (DSTSK_DEF_LNUM) 


See eeeceeeeee eee ee eeeee cesses eeeeeeeeeeeseeeesoescoeoeeeeceeseoceeceseos + 


‘ Unused (Must Be Zero) } 


peer nro nr ten men eno w ene een one ees ce ewtenwenaccaca seeeoe See eee eeeaenaneane + 


' DSTSL_DEF __LNUM_LINE ' 


Gceeceeseeeseososseesesoseseseso eee eeoeeee See eee eee eeeeeneaaneaeo — *224 


Define the fields of the Definition Line Number DST record. The unused byte 


in the DST record is reserved for future use. 


ELD DSTSDEF_LNUM_FIELDS = 
Pe TSt DEF LMU. INE = (€ 3, Lt. ] ! The definition Line number 
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THE STATIC LINK DST RECORD 


The Static Link DST record apes ti tes the “Static Link’ for a routine. 
The Static Lok is a —— to the v AX call rene for the proper up- 
scope invocation of t Geer rout ~ within wh sgh the present nvoca= 
—* of the oe routine is nested. The Static Link is thus used 
en DEBUG doe neem addressing in response to user commands. A 
Frente Link dst Record s always associated with che nner-most see 
within whose Routine-Begin ang Routine-End records it * nested. 
Static Link DST Record is optional--it need not yee yee 
or for routines which do not keep track of static Links 
time environments. In fact, the Static Link DST record quis ge Be a 
difference for recursive routines that. pass routines as parameters, a 
fairly obscure situation. 


This is the format of the Static Link DST record: 


yr i on ueges” 
r run= 


1 

! 

1 

' 

' 

' 

t 

' 

‘ 

' 

' 

1 

' 

' 

! 

a) 

' 

— 

J 

' eras 
! byte ; DSTSB_LENGTH H 
' Gowoeseocescoossossooconsousesesoocesooceecccouscecccccescooocos & 
J 
1 
' 
— 
J 
' 
1! 
' 
' 
! 
1 
] 
J 
— 
' 
J 
4 
F 


i byte | DSTSB_TYPE (=DSTSK_STATLINK) ' 


orem erro wawwooenoewe eeeeeoe See ee eee eee ——— See eee eee eeeeeneneaeane mm ee 


i var DSTSA_SL_VALSPEC 
A DST Value Specification Giving the Value of the 
Static Link, i.e. the FP Value of the Routine Invocation 


Statically Up-Scope from this Scope 


‘ 
' 
‘ 
‘ 
‘ 
‘ 
‘ 
‘ 
‘ 
' 
' 
‘ 
‘ 
‘ 
‘ 
; 
ge ace csce nen eee eee eee SKK BBO EBB oanr ee erie ee mae me oe 2 


i Define the fields of the Static Link DST record. 
FIELD DSTSSTATLINK_FIELDS = 


DSTSA_SL_VALSPEC =(€2, A, ] ! Location of Value Spec iving 
TES i the up-scope FP value 
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' 
i 
; 
: 


byte 
byte 
long 


THE PROLOG DST RECORD 


The Prolog DST record tells DEBUG where to put routine breakpoints. 
it_is used for routines that have prolog code that must be executed 
before data objects can be freely examined or otherwise accessed 
from DEBUG. Such prolog code typically sets up stack locations and 
descriptors for formal parameters or other data objects. By putting 
routine breakpoints on the first instruction after the prolog code 
as specified in the Prolog DST record, DEBUG ensures that all Local 
storage and formal parameters are accessible to the user. 


Prolog DST records are optional. If omitted for some routine, DEBUG 
simply uses the routine start address for routine breakpoints or 
tracepoints requested by the user. If specified, the erates DST 
record is counted as belonging with the nearest Routine Begin or Entry 
Point DST record before it, not counting nested routines. Placing 

the Prolog DST record immediately after the Routine Begin or cntry 
Point DST record with which it is associated is good practice. 


This is the format of the Prolog DST record: 


See reece ee ee eeeee SSeS eSeSSeSeeeSSSSeeseeeeseoeoeooocoooooanooasanoaceca + 


DSTSB_LENGTH (=5) 


foe wo ronr 2— eeecoee SSS SSS SSSSSSSSSSSSSSSSSSS SHSVSSSESES2E82 ware wmee + 


H DSTSB_TYPE (= DSTS$K_PROLOG) ' 


Pee ecemmen en wenrerwonaenae — — —— See ee ee — — 2222— ——— 


DST$L_PROLOG_BKPT_ADDR 


Define the fields of the Prolog DST record. 
IELD DSTSPROLOG_FIELDS = 


Fert PROLOS SEPT AOR s{2,.t. ) ! The routine breakpoint address 


? 
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THE VERSION NUMBER DST RECORD 


The Version Number DST record gives the version number of the compiler 


toe ecee — —— — — SSS SSS 2 22 2 —— — — 2 — — — —— 222—— mee mem + 


Define the fields of the Version Number DST record. 
IELD DSTSVERSION_FIELDS = 
SET 


DSTSB_VERSION_MAJOR 
DSTSB_VERSION_MINOR 


! 

i 

: 

: 

i 

4 that compiled the current module. The Version Number DST Record must 
: be nested within the Module Begin and Module End DST Records for the 
: module in question. DEBUG ignores this record except in spe ial cases 
: when it is necessary to distinguish between old and new versions of the 
: compiler that generated a given object module. 

This is the format of the Version Number DST record: 

: 

i $0 OS 6 OSS SSS SS SS SSSSSSSSSSSSSSSSSSSSESSSESESESEGEESESEEES eae Se ee ca 

} : DSTSB_LENGTH (= 3) H 

; : DSTSB_TYPE (= DSTSK_VERSION) : 

: DST$B_VERSION_MAJOR : 

: DSTSB_VERSION_MINOR 

i 

i 

i 

i 

i 

F 


‘ ¢- B_ 4 ! The major version number 
a ! The minor version number 


THE COBOL GLOBAL ATTRIBUTE 
DST RECORD 


The COBOL Global Attribute DST record Wen that the symbol whose 
° 


attribute specifies that the symbol is visible in nested COBOL scopes 
(routines) within the scope (routine) in Rie the symbol is declared. 
Without this attribute, a symbol is only visibl 

ration but not within any nested scopes. In this reg 


order to implement the COBOL scope rules correctly. 


The COBOL Global Attribute DST record is only generated by the COBOL 
compiler. If it precedes the DST record for some symbol, that symbol 
is deemed to have the COBOL global attribute; if it omitted, the sym- 
bol is deemed not to have the global attribute. DEBUG ignores this 
attribute for ail other Languages. 


This is the format of the COBOL Global Attribute DST record: 

ü aenr sense sew ee 22222 — ree nee tee eon Be Eons DO meee ew omen noes woe + 
byte : DSTSB_LENGTH (= 1) H 
byte ; DST$B_TYPE (= DSTSK_COBOLGBL) ' 


a en were eens wet 


7 
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DST record sanegiotely follows has the COBOL ‘‘global"’ attribute. This 
a 


e in its scope of decla- 
ard. COBOL differs 
from most other languages. DEBUG thus needs to know this attribute in 


= l 
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THE OVERLOADED SYMBOL DST RECORD 


NOTE: THIS DST RECORD IS NOT SUPPORTED BY DEBUG v4.0. 


The Overloaded Symbol DST record is used to indicate that a given 

S l name is overloaded. The record indicates which other symbols 
in the DST are possible resolutions to the overloading. It is used 
by the ADA compiler. 


n the same scope. If the routine name is R, DEBUG disambiguates the 
individual instances of the overloaded routine name with the invented 
names R__1, R_ R__5, and so on. DEBUG requires the ADA compiler to 
generate normal bsT"Fecords for these routines, using the invented 
names. DEBUG also requires the ADA compiler to generate the Overloaded 
Symbol DST record with the original overloaded name ‘'R'’ in order to 
inform DEBUG of the overloading. 


After the length and type fields, this record contains a Counted ASCII 
string with the name of the overloaded symbol. Following the Counted 
ASCII string, there is a word field containing a count of the number 

of overloaded instances of the name in this scope. Next there is a 
vector of pointers, one for each instance, pointing to the DST records 
for the instances of the overloaded symbol. These DST pointers consist 
of byte offsets relative to the start of the whole DST. 


This is the format of the Overloaded Symbol DST record: 


n ADA, it is possible to have more than one routine qf + Bere name 
i 


ben men ——— —— ——⸗ — — — — 2 — — ù— ⸗ — 222 2 2 2—2 — — ——— —— —— —— — 


A Vector of Lonquord Pointers to the DST Records 
of the Symbols with Invented Names that Constitute 
the Instances of this Overloading 


we EE i ae et AR EM BEE 4 
we CTE neat bal Be oth nae am net bed Ik : 
——— ——— ——— 
— The Overloaded Symbol Name in ASCII 
(The name's Length is given by DST$B_OL_NAME) 
—J — — ——— 
word ; DST$W_OL_COUNT 
———— ne) 


—— —— — 4 
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+ 


1 
1 
i 
1 
Define the fields of the Overloaded Symbol DST record. 
FIELD DSTSOVERLOAD_F 1ELD! 

DSTSB_OL_NAME = ( 2, B_ ], 

DSTSA_OL_TRAILER= C 3, A_ J 

TES; 


Count Riky of the overloaded symbol 
name Counted ASCII strin 
The trailer fields start. at this 
location + -DSTSB. OL NAME 


! Define the fields of the Overloaded Symbol DST record trailer portion. Also 
i define the corresponding declaration macro. 


FIELD of epee TRLR_FIELDS = 


DST$W_O ae 2 0, Ww —* 1. ! Number of instances in this scope 

DSTSA_ R “VECTOR = Lae i Vector of DST pointers to instances 
* i of overloaded symbol 

\ES; 


MACRO 
DSTSOVERLOAD_TRLR = BLOCKC BYTE] FIELD(DSTSOVERLOAD_TRLR_FIELDS) %; 


' This is a short BLISS example of how the trailer fields are accessed: 


LOCAL 
DSTPTR: REF DSTSRECORD, 
OVERLOAD_C 
OVERLOAD. 01 

F Bst TSOVERL OAD. TRLR, 


1 

1 

' 

1 
Pointer to DST record 
1 

OVERLOAD VECTO 
i 

1 

1 

‘ 

i 

1 

1 


The number of overloadings 
Pointer to DST record trailer 


Vector of DST-record pointers to the 
instances of this overloading 


P OECTORE, LONG); 


OVERLOAD_TRAILER = DSTPTRCDSTSA_OL sw A + egusryrecosten OL NAME); 
OVERLOAD- COUNT = OVERLOAD _TRAICERTDST$B_0 NT); 
OVERLOAD" VECTOR = OVERLOAD TRAILER DST$A_ “Ot “VECTORS; 


Here we assume that DSTPTR points to the Overloaded Symbol DST record. 


F 7 
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byte 
byte 


var 


CONTINUATION DST RECORDS 


When the text of a Debug Symbol Table record is longer than 255 bytes, 
it is no longer possible to hold that text in a single Be! record since 
the DSTSB_LENGTH field cannot hold a value larger than 255. In this 
case it iS necessary to generate the original DST record followed by 

as * Continuation DST records as — to hold the full text. 

The or pina DST record then holds at least 100 and at most 255 bytes of 
text. Each Continuation DST record consists of the standard two-byte 
header followed by the continued text of the original DST record. 


This is the format of the Continuation DST record: 


bowen ee —— —⸗ TT Se SET — 2 2 © @ TE BF eS PM Bentsen — — — — — — — — — an wre 2——— ——2 


DST$B_LENGTH ; 


Femme — eee een ene mee ee wee ee we Seen eee eeeosae Sees eon en ener mana nea= ad 


; DSTSB_TYPE (= DSTSK_CONTIN) ; 


—— — ù— — wrererwe wre rr eZ — 2 ®e®e — © — eee — — — — OO — — — — — — — — wor — — — —2— * 


The Continued Text of the Previous DST Record 


4 
—E—————— — 


DEBUG reconstitutes a continued DST record by — the text 

of the first DST record with the text portions of its Continuation DST 
records. In effect, the first two bytes of each Continuation DST record 
are stripped out. Any further interpretation of the DST text is then 
done on the concatenated copy. 


Certain kinds of DST records are not allowed to be continued with Con- 
tinuation DST records. These records are Module Begin, Routine Begin, 
Block Begin Label, Label-or-Literal, Entry Point, SECT, Line Number 
PC-Corre ation, and Source File Correlation DST records. In addition, 
DST records with fixed sizes, such as Module End and Ruutine End DST 
records, are not allowed to be continued. Line Number PC-Correlation 
and Source File Correlation DST records cannot be continued with Con- 
tinuation DST records, but one can have multiple such records in one 
module; they can thus be continued, but through a different mechanism. 
The records that really need to be continued, such as Standard Data 
DST records and their variants (Descriptor Format and Trailing Value 
Specification Format records), Separate Type Specification DST records, 
and Type Specification DST records, can all be continued using the 
Continuation DST record mechanism. 


Define the fields of the Continuation DST record. 


_——n 
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FIELD von 5 peat IN_FIELDS = 
Fare. Cont im = €2,A,] ! Address of continuation text 


H 
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OBSOLETE OST RECORDS 


There are several obsolete DST records. These are records that were 

at one time generated by compilers, but are no longer used by any cur- 
rent version of any Digital compiler. Some of these records were not 
groperty thought out and were abandoned when it was realized that their 
ntended uses could not be implemented. Others were at one time used 
and useful, but were generated by now-obsolete compilers. Such records 
are not generated by current compiler versions, and the capabilities 
they grertees are now provided by more general mechanisms in other DST 
records. 


None of the obsolete DST records should be generated by any future 
compilers, and their use will not necessarily be supported by DEBUG. 


THE GLOBAL-IS-NEXT DST RECORD 


The Global-is-Next DST record is now obsolete. It consisted of just the 
DSTSB_LENGTH byte and the DSTSB_TYPE byte. DSTSK_GLOBNXT was the type 
code. The purpose of this record was never properly thought out and 

no support for it was ever implemented. It should not be generated by 
any future compilers or compiler versions. 


THE EXTERNAL=IS-NEXT DST RECORD 


The External-is-Next DST record is now obsolete. It consisted of just 
the DSTSB_LENGTH byte and the DSTSB_TYPE byte. DSTSK_EXTRNXT was the 
type code. The purpose of this record was never properly thought out 

no support for it was ever implemented. It should not be generated 
by any future compilers or compiler versions. 


THE THREADED-CODE PC-CORRELATION DST RECORD 


This DST record is identical in format to the Line Number PC-Correlation 
DST record except that the record type code is DSTSK_LINE_NUM_REL_R11. 
It was used by an obsolete COBOL compiler according fo legend (the memo- 
ries are a » ao | by now). The idea was that the threaded code gene- 
rated by this comp ler consisted of a vector of longwords where each 

t rd contained the address of ? run-time support routine to call. 
Register R11 pointed to the beginning of this vector. The code — 

$s 


rated for a source line thus consisted of some number of longwor 

with addresses to call (or perhaps jump to--the exact details are lost 
in the mists of time). The Line number PC-correlation information 
passed to DEBUG consisted of Line numbers correlated with byte-offsets 
relative to R11 (i.e., to the start of the threaded code). Breakpoints 
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were placed on a specified Line by looking up the correspending offset 
relative to R11 and then gter ine an address within DEBUG into that 
location. When the location was reached, DEBUG was entered. DEBUG 
could then convert the ‘PC’, i.e. the threaded-code location, back to 

a Line number to announce the breakpe int. It is not clear how, or even 
whether, tracing, stepping, and watchpoints were implemented. 


The Threaded-Code PC-Correlation DST record is no longer supported by 
DEBUG and should not be generated by any current or future compilers. 


THE COBOL HACK DST RECORD 


The COBOL Hack DST record was at one time used to support formal argu- 
ments to COBOL procedures. It has now been superceded by the more 
general Value Specification mechanism, and is thus obsolete. It is 
no senger generated by the COBOL compiler, and it should not be gene- 
rated by any current or future compilers. Future versions of DEBUG 
may not support it. 


The fields of this record consist of the fields of the Standard Data 
DST record followed by a type field that specifies the data type and 
then a sequence of commands for the DEBUG stack machine. (See the sec- 
tion on Value Specifications for details on the DEBUG stack machine.) 
The result of interpreting the stack machine routine is the address of 
the object described by this record. The DST$B_VFLAGS and DST$L_VALUE 
fields are zero unless the object has a descriptor. In this latter 
case they specify the location of the descriptor. The result of the 
stack machine routine is placed in the DSCSA_POINTER field of the 
descriptor before it is used. In addition, if it is an array descrip- 
tor, the DSCSA_AO field is added to the result of the stack machine 
routine and the result is placed in the DSC$A_A0 field before the 
descriptor is used. 


The type field following the name field contains the VAX Standard Type 
Code of the object be ting described here. If the object also has a 
descriptor, its DSCSB_DIYPE field must agree with this code. 


The stack machine commands used in this context are those described 
in the section entitled ‘The DEBUG Stack Machine’’ in the chapter on 
DST Value Specifications. 


This is the format of the COBOL Hack DST record: 
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byte 
byte 
byte 
Long 
byte 


var 


byte 


' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
: var 
' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
F 


Define the fields of the Cobol Hack DST record. 
macro for the trailer fields. 


IELD DSTS$COB_HACK_FIELDS = 
Geren COBMACE TALR =(€ 8, A, J] ! Location of trailer fie 


Fermeeceeeeoesoeoesoeoeeoeeeeooeoeeeoesooeoesoeesoeseses eR Se a Se me et ae am oe a ce we ee + 


' DSTSB_LENGTH ' 


+ Serr een Zeer eee eet eee ett fee meee eaowetee2eoe mer ewwreeoeoeroeoc ee ast eecermaereee * 


DSTSB_TYPE (=DSTSK_COB_HACK) 


¢ were eee eee eee mm ee meme mee eo oem em ecm mec emcee emo coe wees mee eee o ec oae -- * 


DSTSB_VFLAGS ' 


c 7 Seer eee nan wn oer Be eB ee Dewar — See wnee we wewoeneoawve ceaesceanoannane — 


DSTSL_VALUE : 


+ COSTE sec reneew ent ewe ean an enema tw er we rw wm tenner wa weno — awe eae nr neem ano a=s + 


' DSTSB_NAME ' 


+ eer err er ee em Pe Pew e tT we tM — ee weet eenreoerereacwrerceanecececoeeeaoecee + 


The Name of the Data Symbol in ASCII 
(The name's Length is given by DSTSB_NAME) 


a NO EN eeeeceoe + 
: DSTSB_CH_TYPE } 
¢woeeecoeeceeeoesoeeooesoeeeeeeeeseeoeooeoocesoescosoeeoeeoceses — — —— eee — — wow} 
' DSTSA_CH_STKRTN_ADDR 
Instruction Sequence for the DEBUG Stack Machine 
— v 


FIELD BST OEM _TOLA_F IELDS = 


MACRO 


DST$B_CH_TYPE 
DSTSALCHISTKRTN, ADDR 


“wu 
wr 


9. B. }- ! VAX standard data type 


DSTSCH_TRLR = BLOCK BYTE) FIELD(DSTSCH_TRLR_FIELDS) 2%; 
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Also define the declaration 


lds 


! Start of stack routine code 
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' 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 
i 

F 


: ver 


VALUE SPECIFICATION DST RECORDS 


The Value gig DST record contents nothing but a DST Value 
5 cificat However, there appears to be no use for this record 
since att DST value spect ications that are actually used appear in 
records. $s record use probably designed with some use 
rbot. was then aba néones., . pen better weys of addressing the 
* need were devised. ane this DST record, and it 
s believed that no — * el 
should not be generated by any future” compilers. 


This is the format of the Value Specification DST record: 


+ SSS SSS SBS SSSSSSSSSVSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSISSSSSSSSSSES + 


' DSTSB_LENGTH ' 


Geewoeeoossoesocssosesosseeecseseuseseseseosesoosesososecsosesece + 


: DSTSB_TYPE (= DSTSK_VALSPEC) 


ö —————————— —————— —— ——— 


A DST Value Specification 
‘ 


i Define the fields of the Value Specification DST record. 
FIELD DSTSVALSPEC_FIELDS = 


DSTSA_VS_VALSPEC_ADDR = [ 2, A_ J 
TES; 


! The start location of the 
i Value Specification 


penerete it. This OST record 
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This ma 
REF DST 
the, var 


fields 


or example, wou 


dSsT 


RECORD 


ro allows BLISS s ty? 
ECORD to be qualif 
-= oer Fecere 
arate s 
in bst recerds: 6 


vornets 
ls for tietd 


DECLARATION 


MACRO 


ols which are 43 DSTSRECORD or 
n 


ed by A 


antic} pated 
sets which describe trai 
ointer to the PSECT 
would be 4 ared to be a REF DSTSPSECT_T 


d names present 
hat —— 


ST fecore trailer, 


Separate macros are supplied above for all such reiter Met as. 


1 
' 
t 
1 
1 
1 
' 
; lere 
1 
1 
i 
1 
1 
1 


i Define the declaration macro for all DST records. 


CRO 
DSTSRECORD = wit (256,BYTE) FIELD( 


DSTSHEAD 
DeTSstD 
DSTS$OS 


! END OF DSTREC 


C-FIELD 


ADER FIELDS, 
FIEL «ty 


QOVHeMo YrouUNuNunuwnnm 
mem -« Ouvre «ee & 


“Me 
. 


RDS.REQ. 
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